Can you be sure of this? As far as I know, the lower levels of the network stack will deal with most radio issues, you will not see any corrupt data being sent up to the application layer.
I have no other way of knowing... I understand that nothing will get corrupted when the packet arrives. But, there is still no guarantee that the transmission radio didnt produce the issue at that moment in time.
I am using a LM Technologies Bluetooth COM port radio at the other end. It is a high power radio that has about a 300 foot range in open spaces.
I know its not the Atmel AVR (BASCOM) code, Its setup to produce the prefix correctly. Here is the transmission code on my Acknowledge OK packet:
'We Drop here when a command process has succeeded, and no data has been requested or supported.
Sub Rsp90()
Prefixheader(1) = 0
Prefixheader(2) = 0
Prefixheader(3) = 0
If Ismaster = 0 Then
If Slaveaddress <> 0 Then 'If this board is configured as slave, we DONT respond.
Reset Flags.4
Reset Flags.6
Exit Sub
End If
End If
Packetbuffer = "120190"
Call Dochecksum
Packetbuffer = Packetbuffer + Hex(checksm)
Length = Len(packetbuffer)
Length = Length + 2
Prefixheader(4) = Length
Printbin Prefixheader(1) ; 4
Print Packetbuffer
Reset Flags.4
Reset Flags.6
End Sub
The packet sent in hex representation would be:
00 00 00 0A 31 32 30 31 39 30 38 33 0A 0D
0D is the carriage return, its part of the BASCOM-AVR Print statement.
I use Print, because I am working with HexStrings and not binary packets. But the Async has to be in binary, so its sent as binary.
the AVR code strips off the binary on a receive as It doesnt care about it, and this incoming direction NEVER has issues. its the outgoing direction.
Now I could work entirely in binary, But I am too lazy to do the conversions and all that jaz, So i did it this way and it works ok.