2

I'm currently using an STM32F103C8 (With an arduino core) to read 4 sensors at 1kHz, then send that data via UART (at 115200 baud) to another device. Each sensor returns a float, I also include an unsigned long representing milliseconds since boot time. This adds up to be a 20 byte package, that I attempt to send at 1kHz. Sensor sampling is carried out via a timer interrupt, as it is crucial the time between samples is constant.

The data transmission itself (If I send it slowly) takes approx. 70 microseconds. When sped up to 1kHz, it takes approx. 2500. I assume this is because I am filling a serial buffer of some sort.

Is this about the limit of the communication method? If it takes longer than 1000 microseconds to send the data, then presumably the interrupt will trigger before the data is sent and it will have to start again?

Improve this question
1
  • You could try a higher baudrate. Though that depends on how high a baudrate the other device can handle
    – chrisl
    Nov 17, 2020 at 11:55

2 Answers 2

Reset to default
3

At 115200 baud you can send 11520 characters per second. At 20 bytes per packet you can send 576 packets per second. That's 1,736µs per packet.

That's assuming zero wait between bytes. That's not going to happen.

Your measurement of 70µs will just be the time taken to place data into the transmit buffer, and has nothing to do with how long the transmission itself takes.

Roll all that together and the value of 2,500µs per packet is not unreasonable.

To transmit faster you will simply have to run at a faster baud rate. If you're getting 2500µs per packet currently and a packet takes 1736µs (call it 1,750 for simplicity) then there's about a 750µs overhead per packet to do the actual work of sending the data from the buffer. I'll assume this is a fixed value, though with no knowledge of how the STM32F1 UART works it may not be.

If you want <1000µs then that leaves you about 250µs of time to fit the packet into. That means an equivalent of 4,000 packets per second, or 80,000 bytes per second, or a baud rate of 800,000baud.

1 MBaud is more than possible, and is a good standard baud rate number that most things can cope with. So raising your baud rate to 1,000,000 should allow the communication to happen fast enough.

Improve this answer
3
  • Interesting! I wasn't really aware such high baud rates were feasible! I have had some success with a rate of 921600 rather than 1000,000, so presumably something to do with a multiple of crystal frequencies
    – nuggetbram
    Nov 17, 2020 at 13:00
  • The closer you are to an integer factor of your clock speed the more accurate the baud will be. But if both ends of the connection use the same clock the error difference between the two ends will be 0 so is meaningless.
    – Majenko
    Nov 17, 2020 at 13:57
  • Of course at higher baud rates you're more at the mercy of the clock accuracy, as any slight deviation in clock will cause a bigger percentage of difference in the baud rate.
    – Majenko
    Nov 17, 2020 at 13:58
0

I tested a lot of baud rates on Arduino Unos, including cheap Chinese models, and decided to use a default 115200 for my DaqPort system (https://www.daqarta.com/dw_rraa.htm). I had found problems, like the system hanging after a second or so at 150000 baud, and didn't want to have my users run into issues that would be hard to troubleshoot.

So I'm wondering if you can reduce the bytes you need to send. Do you really need to send floats? I'm thinking 4 bytes for the data and 4 for the time would give ample resolution for almost anything, and I can't (off the top of my head anyway) think of a sensor type with more than 32-bit resolution. Also, 32 bits of msec is nearly 50 days; if you need more than that it should be pretty easy to unwrap the times after the fact.

Just a thought...

Improve this answer
1
  • I had honestly completely forgotten about shorts as a datatype, my sensors are only 12 bit anyway so that's going to help a huge amount. I should be able to just store a raw sensor reading as a short and post-process everything to floating point later. I'm using microseconds rather than millis for time, so the unsigned long is only 70 minutes - my max sampling duration is 20 minutes, so too long for an unsigned int.
    – nuggetbram
    Nov 18, 2020 at 6:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.