tobalt

@NickAlexeev DDS you mean? you only need a sample rate of 44 kHz for these frequencies. So should be simple enough by outputting a new sample via DMA and calculating the next same at the same time. Just linearly increment the phase each time, and the either calc a sine wave (if there is enough time) or look it up from a table and interpolate

@uhoh I found regular FR4 quite good (not in space but in terrestrial UHV), but there are a few caveats: reflow air bubbles in solder should be avoided, flux residue MUST be carefully removed. limit heat exposure, so the board shouldn't be in direct sunlight. But outgassing limits for sensitive space instruments might be stricter, so idk really

@Lundin I want to measure accurately the average duty cycle, but say the timer clock is 32 MHz and the signal is also in the MHz range. The one answer suggested the "gated mode" which sounds kinda appropriate but I didn't have time to test it

Fair. I only joined after the - let me call it - "politicization" happened, so I'm kinda agnostic about these platforms and SE simply was was "stuck" back then

@NickAlexeev Ehh I was thinking about codidact in the past, but decided against it thinking that I'd essentially only go there if I didn't get an answer on SE

This is approximately the most basic timer function I can think of coming from an FPGA, yet I'm too dumb to find anything about it for microcontroller timers..

@Lundin a question for microcontroller people ;) electronics.stackexchange.com/questions/752023/…

Microphones picking up EMI is pretty inevitable. The rectification of the RF into audio band patterns happens in the semiconducting parts usually. So I would think about putting proper low pass filters before the amplifier

Literal fingerprints will corrode copper lol. The tiny amount of salts is enough with the air humidity to attack bright copper surfaces over time

So copper basically ticks all the boxes in the "bad" list lol

copper in general is one of the most instable metals when it gets to corrosion. almost no copper salt is insoluble in aqaeous solutions, it oxidizes readily, and in contrast to almost every less noble metal, its oxide isn't self passivating

piranha attacks copper tho

I'm definitely trying these

I think "solderable magnet wire" can be a term getting you there

"Modified polyurethane"

This link seems to confirm the PUR: remingtonindustries.com/magnet-wire/…

I have tried a lot of chems to dissolve enamel, but its either not fast, too damaging to copper or just meh...

WHERE? GIMME

Apparently cutting, stripping and tinning enameled wires is a significant fraction of our assembly times :o

Do you people know if it is possible to buy enameled copper wire cut to specific lenghts with tinned tips?

(or derivativees) seems to be totally appropriate for short links I had in mind

RS485

But good to know, that the short range wired field busses seem to be based on RS 485...

I feel uneasy around RS-485. If you need a long cable based comms links, it should have galvanic separation, so Ethernet or optical comms. As as fibres tend to break, Ethernet it is.

My initial plan for prototyping that is to use virtual COM over USB.. But I suppose the industrial partners will want something else down the line

@NickAlexeev I suppose the distance max between the sensors and controller will be max a few meters, so say 10 m max. And per controller, there will be only a few sensors, less than 10 I guess. Or even a single one.

I mean, it's relieving to know that most of these busses are in the process of dying. Sounds like a sane trend.

I fully intend to remain uninformed after this potential chance encounter with fieldbusses. Should be a one-off project in that domain I guess

So your opinion is the "CAN ecosystem" or "something based on Ethernet" coarsely speaking?

on payload is 16 bit, though maybe let's say 18 bit plus some overhead, i.e. 3 byte

@Lundin basically the latency from when the sensor begins streaming a value until both of the following things have happened: a) the controller has read the value and can begin processing it b) the sensor can begin sending the next value

Though I guess, there is no issue in providing two separate power wires in the cable, if the fieldbus type does not impose a specific cable format that leaves no room for additional power wires

And I need a tiny bit of bus power

@Lundin If we want to exchange something like 10kS/s (or more) with a latency ideally below 100 us does that narrow the field of useful busses somewhat?

On a separate note I am reading up on field busses for a small project description for a sensor module. And I am wondering whether it's possible to make an informed choice of a field bus without regrets and without hating my life lol

@NickAlexeev thanks I think I see where this is going. Hardware exists, it's generally possible but requires some research some pushing and some convincing ;)

@NickAlexeev that sounds like "SPI is more of a Be-Water-philosophy" ;(

yeah I realize that bit banging is not the way on microcontrollers, which is why I want to understand how people typically approach this kind of communications on micros. again contrast that with FPGA where not bit banging any kind of communications is rather cringe

(background is FPGA where all the pins are DIO, because you can bitbang deterministically whatever interface you want. But I reckon this is not gonna work on microcontrollers as bitbanging would require the CPU.)

And in terms of streaming can streaming from/to such an SPI engine be handled in hardware too via some kind of DMA, or even streamed to another peripheral all without CPU?

If so then how could I deal with the plethora of "SPI-esque" serial formats used by various ICs such as ADC and so on

Another generic microcontroller question if I may: many parts have dedicated "SPI" pins. How are these different from DIO pins? does it mean there is some kind of hardware serial engine to which I can write/read e.g. 32 bit values and which then goes on to serially send/scan this from the "SPI" pins?

something called "5V" is usually not very accurate to begin with lol. Unless it's called "5Vref"

If you have a controlled 2.5V elsewhere in the project, you should run the resistors to that instead btw

It will be as accurate as you R2/R3 tolerance and V1 tolerance allow

I mean even I would use the firmware to tune the actual gain, so I could use some random resistor values that aer already in the Bom

I thought, the offset and gain inaccuracy is something you would account for in the firmware ;)