I have an RF module attached to an imp device which communicates with the imp device via UART. I’ve been experimenting to improve resilience and went and sent the RF module a configure command to change the stop bits from 1 to 1.5 assuming that Imp UART could be configured to this too, but it appears not according to documentation.
Just want to check that this is correct and not an oversite on the documentation. If that is the case is there any workaround as I cannot now communicate with my RF module at the moment. Was there any reason for not implementing 1.5 stop bits.
1.5 stop bits is unusual. The only time I remember seeing that is with devices that had serial frames with less than 7 data bits, which would make it hard to manage on the imp UARTs as they stand at the moment.
Is your RF module communicating in half-duplex? If so, you could consider sending with 2 stop bits, then use uart.flush() to block until the last frame has been sent, As soon as flush() completes you would configure the uart to 1 stop bit to receive the response.
Another option would be to use 2 uarts. Your TX UART would be set to 2 stop bits and your RX UART set to 1 stop bit. That way, your imp can still safely communicate with anything set to 1, 1.5 or 2 stop bits
As @coverdriven says, 1.5 stop bits is unusual. What resilience problem are you actually having that you are hoping to fix here? Does the RF module have a problem with timing accuracy? (that’d be unusual for most RF modules)
A case of live and learn with these snags. Yes 1.5 is unusual but then thought an incremental change is better when experimenting than jumping straight to 2 bits. Thanks @coverdriven for the helpful pointers. Using 2 stop bits worked but had to resolve it using my favourite RS232 comms tool: Termite . Termite also does not have 1.5… so imp is not alone.
@hugo when my RF modules are at +150m away my data was being corrupted. I reduced the baud rate right down to get my comms working but about 25% of the time my data was corrupting as it appears to merge my payload (as in my imp did not always get the each transmission and this was then coming through with the 2nd payload - so somewhere inside my rf module it is buffering thinking there is more data to arrive). So thought adding extra stop bits would help as well as do a parity check.
So, hmm. More stop bits doesn’t prevent bits from getting corrupted; what more stop bits helps with is re-acquiring sync if timing is lost. Generally if you want more range you’d reduce the data rate. Which modules are you using?
@hugo Like to keep it simple. Using a SI4463-based wireless HC-12 Serial Port Module @ 433Mhz. You just fire through strings using uart and it has an onboard mcu with an AT instruction set that does the rest. As you say keeping the baud rate low, makes a big difference and not much else matters to prevent payload corruption. To improve things my end I’ve shortened my string lengths right down, I’ve affixed multiple control strings (e.g. just using “\r
\r
”) at the end of my strings so if strings merge I can split apart etc. and I duplicate send in some cases.
At some stage may consider using just a SI4463 RF module to give me more control over messaging than what the HC-12 offers, but then more grunt work required to handle messaging reliability and anyway I think the performance and ease of use of the HC-12 is fantastic.