Serial Data Transmission with RF - Receiving Notes Part 3

In preparation for range testing I made a leap of faith and decided to improve the speed of the receiver code with still more assembly code. I felt the code was fast enough. However, but I wanted to be sure that if I sent two packets with a short gap, say 2ms, that the receiver would be ready 2ms after the previous packet finished

It was a relatively smooth exercise. That's testament to how the design choices in STM8 eForth set it apart. And the power of Forth itself. Interactively testing at the console is so far in front of a "compile upload debug" model many languages require.

So after fetching 9 pulse lengths (PL) I did a thumb suck on how long it would take:

9 PL x 10 clock cycles to process each PL = 270 clock cycles.

Say 20 clock cycles to use the byte received

Clock speed of 16MHz means 290 clock cycles equates to ~18uS

So even if the next byte starts 50uS after one finishes then the micro should be ready. Now I'm comfortable that I can send multiple bytes with a short delay and missed packets are the result of being out of range.

 

Lesson learned - the preamble should never be a start pulse.

I had a hunch, given the strange stuff going on today, that the soldering of the receiver to the base board needed touching up. That seemed to transform the receiver and now there was no noise between bytes on the data pin.  I thought that was a real win. 

While the noise returned, which really annoys me, it turned out to be masking another issue. As it turn out, grabbing the 9th pulse when there was no noise meant the preamble from the following packet was grabbed. So the time it took to  process the 9 pulses, while short, meant that the measured pulse length for the next start byte was just outside the window I had allowed. So that byte was skipped altogether.

It took me some time to work this out. The grabbing of 9 pulses was a relic of when a packet commenced with 2 start pulses. Far better, in my opinion, to simplify the processing of received pulses to only have one START pulse. That way you don't have to deal with the possibility of an extra start pulse.  So far better that the preamble is nothing like a start pulse.