0

In software serial, the write function only sends 1 byte at a time. Is there someway, some library, that i can send multiple bits/bytes, without stopping (and not using digitalWrite)? i want to be able to transmit at least 16 bits as opposed to just 8.

I know i can send 2 bytes, or even 100 bytes. But the thing i'm trying to do is, implement my own LDPC(error correction) codes on the Arduino. Therefore, i'm taking a lot of channel measurements. One of them is figuring out how the error happens during the delay between the stop bit and the next startbit. Often times, this is were synchronization problems occur. So I'm trying to track this down. Hence why, I need to send more than 8 continuous bits. In software serial, it transmits 8 bits, then transmits the stop bit. then write() restarts on the next call. Instead of this, i just want to send more bits, like 64 bits for instance, and look at the BLER on the received data. (the reason why I'm staying away from hardware serial is because i'm doing this with wireless RF modules) Do you guys have any further info regarding this? I'm very grateful! Thank you so much!

Also, it was suggested that I write my own softwareserial, but that's a pretty daunting task. I would like to avoid it, if i can.

EDIT: Let me show you my data. So, I'm constantly transmitting the values; 123,124,125,126.

1111011
1111100
1111101
1111110

The above 4 lines repeat about 2 times. Then, suddenly, it synchronizes incorrectly, and the following 4 lines are being constantly repeated.

11110101
11111001
11101101
11110001

It never syncs back to the original 4 transmissions. Now, inside the unsynced block of 4 transmitted bytes, there are fragments of the correct transmission inside. For instance, start from the 2nd bit of the 3rd byte of the correct transmitted byte. Now, if you account for the '0' start bit, and try to matchup the bits, the correct bits are being picked up in the correct order. It's just a problem of what the receiver takes as the startbit.

As i'm typing this edit, i realized something else. What i said in the above paragraph is true, then for the unsynced block, there should be a '0' start bit in front. Now, if the messages match up exactly, and if the 0 start bit that is being transmitted is being treated as a payload, then which 0 is being treated as the startbit, because all the bits between the synced and unsynced data are matched up. However, there should be one missing 0 each time because it's being read as a startbit, not databit.

Sorry if this is convoluted. Happy to clarify any part of it. Thank you so much!!

  • Is it possible to just go into my write function, and just change the loop from iterating 8 times to 32, and then make the parameter take in 32, and do the according changes just in that function? I'm 99% sure changing software serial isn't that simple and that other parts of the code would be affected, but worth a shot. – Jonathan Nov 18 '15 at 5:57
  • 1
    figuring out how the error happens during the delay between the stop bit and the next startbit - there can be any time between the stop bit and the next start bit. – Nick Gammon Nov 18 '15 at 10:24
  • @NickGammon Hello sir, can you please take a look at my edits? thank you so much! – Jonathan Nov 23 '15 at 6:28
  • How much gap (in time) do have between blocks of data? – Nick Gammon Nov 23 '15 at 20:23
  • I've tried both ways. Having no delay and having some delay. With a delay, it works fine. However, my question is how the synchronization can happen the way it is. Because the right data is being shifted and I am able to do a perfect one to one mapping of how it was shifted, however, because the data being read is starting at a different point, there should be one missing 0 that's being treated as a start bit. @NickGammon – Jonathan Nov 24 '15 at 3:03
2

I want to point out here that async serial communications relies on both ends providing a clock (there is no transmitted clock signal). Thus the sender clocks out bits at the "baud rate" (eg. 9600 bits per second) and the receiver clocks them in at the same rate.

With a start bit and 8 data bits therefore you can tolerate some difference in the clocks between sender and receiver (and there will be some difference). Effectively you could probably tolerate around a 10% difference in clock frequencies, as even if they are out by 10% the sample at the receiver will still land inside the data bit of the sender.

Now if you want to transmit 64 bits you have reduced this error margin by a factor of 8. So let's say (ball park) that you can now only tolerate a difference of 1% between sender and receiver.

You now need to be pretty sure that the clocks on the respective boards are pretty accurate. The Uno, for example, has a resonator CSTCE16M0V53-R0 which appears to have a tolerance of 0.5% and a frequency stability of 0.2%.

So, if the sender is running 0.5% slow, and the receiver 0.5% fast, you will almost certainly get errors.


However, when it becomes unsyncde, some new 0 bit should be treated as the startbit, in which case it should not be printed. But i don't see any misisng zero. It's as if the actual data just got shifted.

How will it get unsynced? I don't think you are following how serial comms works. If you don't have any delay between bytes (or batches of bytes in your case) then it is impossible to resync, because if you miss a start bit, all the following bits will appear valid, they'll just be shifted. This is exactly what you are describing.

Really, to ensure syncing you need to have a gap between bytes (or batches-of-bytes in your case) longer than a byte might be, otherwise you can get this mis-sync happening. So if you make your batches longer, the gap has to be longer, effectively removing the slight advantage of larger batches.

Imagine you have an incoming stream of bits on the receiver:

011110101101100011110101101101101100110101100101100110101111001010101110111001010101111
1101001010100101101001010100111011111001000010111100100011011001001001001011001001010

And imagine that you missed that first start bit. Without a gap between bytes (which would appear as: 111111111) you have no way of knowing which is a start bit and which is a data bit. Valid data would have a start bit, so you don't mistake valid data for the inter-byte gap.

In other words, with 8-bit bytes, data will always be 0xxxxxxxx1 and thus a gap of 1111111111 must be the gap and not data because there is no zero there. But with any shorter gap, and if the receiver samples in the middle of byte, it certainly might think that the next 0 in the stream is a start bit (wrongly).

  • 1
    The question concerns transmission via radio, so serial clock differences are probably not the source of error. Rather the poster is investigating channel noise. – Chris Stratton Nov 18 '15 at 17:23
  • @NickGammon, hey, I've made some edits to the question to show exactly what's happening. Thank you so much for all your help, once again. – Jonathan Nov 19 '15 at 16:52
  • @ChrisStratton, Hey, yes, I am investigating channel noise, but it seems that the mis-synchronization ultimately does give me incorrect data as well. My goal, however, IS to analyze channel noise and implement optimal error correction code. But i'm trying to get past this incorrect synchronization problem first. – Jonathan Nov 19 '15 at 16:57
  • Unless you have bad crystals or diverse implementation with badly approximate divider ratios, it is relatively unlikely that there is an actual "synchronization problem" behind what you are seeing. Rather, you are probably seeing noise in the radio channel, possibly noise which is interfering with the detection of synchronization or clock recovery. – Chris Stratton Nov 25 '15 at 2:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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