Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
|
Forum Index : Microcontroller and PC projects : Dumb RF 433MHz Module Code
Author | Message | ||||
GoodToGo! Senior Member Joined: 23/04/2017 Location: AustraliaPosts: 188 |
Howdy All, While waiting for my NRF24L01+ and HC-12's modules to arrive from the Land of the Great White Beef with Broccoli, I decided to have a tinker around with a few Dumb RF modules I have kicking around. I've come to realise they are crap. However after much research around the forums, I managed to un-crap them enough so they work alright. The Transmitter Code:- 'Dumb RF Module example Transmitter code By GoodToGo! 31/05/17 'Transmitter code option Explicit dim STX$ as string = chr$(&h02) 'Start Byte dim ETX$ as string = chr$(&h03) 'End Byte dim Slice$ as string = "UUUUUUUUUUUUUUU" 'For RF module calibration dim Message$ as string dim Payload$ as string dim i as integer Message$ = "He sells seashells by the seashore" Open "COM1:9600" as #1 Payload$ = Message$ + Chksum(Message$) 'Adds the checksum to the Message do print "Sending Payload" for i = 1 to 4 Print #1, Slice$ + STX$ + Payload$ + ETX$ next i pause 5000 loop function Chksum(Message$) as string 'Creates Checksum of the Payload local c as integer = 0 local b as integer = 0 local i as integer = len(Message$) local a$ as string do while (i) > 0 a$ = "&b"+bin$(asc(mid$(Message$,i,1))) c = val(a$) b = b xor c i=i-1 loop Chksum = chr$(b) end function And the Receiver Code:- 'Dumb RF Module example Receiver code by GoodToGo! 31/05/17 'Receiver Code option explicit dim STX$ as string = chr$(&h02) 'Start Byte dim ETX$ as string = chr$(&h03) 'End Byte const MaxMsgLength =50 'Change if your Message is going to be higher dim Rcvdata$ as string dim RxdMsg$ as string dim RxdDataFlag as integer = 0 dim InvalidMsgFlag as integer = 0 dim ValidMsgFlag as integer = 0 dim Debug = 0 'Change to 1 for extra info to the Console open "com1:9600" as #1 'Main Loop do 'Stuff goes here If InvalidMsgFlag then InvalidMessage If ValidMsgFlag then PrintMessage if loc(#1) > 10 then ChkBuffer loop sub ChkBuffer 'Received something local Checksum$ as string = "" RcvData$ = "" RxdMsg$ = "" pause 250 'Time to stack bytes in buffer If Debug then print "Bytes in Buffer = " str$(loc(#1)) do RcvData$ = RcvData$ + input$(1, #1) 'Get one byte from buffer if right$(RcvData$, 1) = STX$ then 'Detected Start Byte If Debug then print "Startbyte Detected" exit do endif if len(RcvData$) > MaxMsgLength then 'No Start Byte detected InvalidMsgFlag = 1 exit sub endif loop RcvData$ = "" Do RcvData$ = RcvData$ + INPUT$(1, #1) 'Increase D$ by one byte from buffer IF right$(RcvData$, 1) = ETX$ THEN 'Detected End Byte If Debug then print "Endbyte Detected" if Debug then print "Message Length = " +str$(len(RcvData$)) if len(RcvData$) < 2 then 'Detected Start and End but message corrupt InvalidMsgFlag = 4 exit sub endif exit do endif if len(RcvData$) > MaxMsgLength then InvalidMsgFlag = 2 'No End Byte detected Exit Sub endif Loop RcvData$ = left$(RcvData$, len(RcvData$) - 1) 'Strip End Byte Checksum$ = right$(RcvData$, 1) 'Get Checksum RxdMsg$ = left$(RcvData$, len(RcvData$) - 1) 'Strip Checksum if Checksum$ = Chksum(RxdMsg$) then 'Checksums match ValidMsgFlag = 1 'We have a good message exit sub else InvalidMsgFlag = 3 'Checksums don't match endif end sub sub PrintMessage Print "Message Received:- " + RxdMsg$ ValidMsgFlag = 0 end sub sub InvalidMessage Select case InvalidMsgFlag case 1 If Debug then print "***No Start Byte Found***" Case 2 if Debug then print "***No End Byte Found***" case 3 if Debug then print "***Checksum Failed***" case 4 if Debug then Print "***Incorrect Message Length***" END SELECT InvalidMsgFlag = 0 end sub function Chksum(message$) as string 'Creates Checksum of the received Message local c as integer = 0 local b as integer = 0 local i as integer = len(message$) local a$ as string do while (i) > 0 a$ = "&b" + bin$(asc(mid$(message$, i, 1))) c = val(a$) b = b xor c i=i-1 loop Chksum = chr$(b) end function I have the Transmitter code running on a MM+ LCD Backpack and the Receiver code running on a Grogster Explore 28. Two CP2102 TTL-USB Converters connect both modules to the one laptop where I am running two instances of MMedit. (I know I could have just used USB cables intead...) Works reasonable, especially with the (UGLY) simple checksum routine I cobbled together. I had to send the data 4 times at once to have the best chance of successful reception at 9600 baud. Dropping the baud to 2400 improves the reception without need for multiple sends. Hope the above routines can assist anyone out there, or conversely, if there are ways to improve the above, please do! Cheers, GTG! ...... Don't worry mate, it'll be GoodToGo! |
||||
drkl Senior Member Joined: 18/10/2015 Location: HungaryPosts: 102 |
Hello, Thank you for your published code, but which kind of dumb modules are using? Cheers drkl |
||||
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9083 |
Yes, 'Dumb' RF modules do not have ANY processing in them at all. I find that the Radiometrix dumb-RF module pairs are VERY reliable - even better then the ones with processors on-board most of the time. This is probably cos the Radiometrix ones being designed in the UK, are designed to more of a commercial application market then the hobbyist market. The Radiometix ones are not cheap either, but the 'You get what you pay for' rule does apply to their modules, as it does to many other things. The Radiometix modules are also fully approved too, which makes integrating them into a commercial product a breeze, as they are already certified for use. But I digress..... With 'Dumb' RF modules, you MUST take full control of exactly how the link operates, not just the data you want, but any checking or syncing of the link. The string of 'U' characters is 10101010 in binary, or 85 decimal, or 55 hex. The constant alternating 1's and 0's sync the data-slicer in the receiver, effectively eliminating the standard background noise that the receiver will output as random rubbish, so that when the first byte of the actual wanted message arrives at the receiver, the connected data-filter chip can then see the wanted message. I still use the 8-pin PICAXE chip as a data-filter connected to the 'Dumb' receiver, and it sits and waits for the qualifier and message, and just goes around in loops like that. I have had extraordinary success with just using 10-15 'U' sync bytes at the start of any message, a qualifier and payload. I generally get a 99% success rate across a 'Dumb' link like that, and with transmitter node re-tries, this effectively comes up to a 100% success rate. No good for streaming lots of data, but if you only need to send small data packets, then a decent quality 'Dumb' module is the bees-knees IMHO, and I tend to prefer these over smart-modules. I also like the 'Dumb' modules, as you can have a very slow over-the-air baud-rate, which increases the reliability even more. Smart-modules will tend to accept a certain baud-rate, but the actual over-the-air baud-rate will be very high to keep the on-air duty-cycle as low as possible. But the higher the baud-rate over-the-air, the better the receiver sensitivity has to be to keep up with the higher baud-rate and not miss any data. Smoke makes things work. When the smoke gets out, it stops! |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1995 |
Hi GTG. Roman Black did a lot of work with these and although the work is primarily aimed at specific PIC code, it is a very valuable resource that I have referred to a lot working with these. Cheap RF Modules Made Easy worth pointing out that they seem to come in two common flavours 315MHz and 433MHz which may or may not be licensed for a particular country (unlicensed 315MHz is not permitted in UK) - and they are DIRTY!!! They have really poor separation and can bleed over a wide band of "channels". Even at legal frequencies you might get a knock at the door if you use them for long "on" periods in urban areas. That said, they are really good for quick and dirty and once you have developed a protocol for handling data, why not? I used a two Rx/Tx pairs to provide a cross-town link (about 450m with external stubby antennas) for a customer to pass orders between his shop and workshop and it is still working really well six years later. Small packets and not terribly frequent at 2400 (edit: it was 1200, just checked) baud. It functions as a transparent pass through with a couple of USB-Serial adapters I built with some custom VB on either side to provide the protocol and encryption (please do the encryption - start as you mean to go on for the "IoT" panic). It just works hth |
||||
Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1664 |
Hi GTG, I'm using HC-12's really successfully at 9600. Regards the "Ugly Checksum".... Didn't try & understand it but this is what I'm using. No my creation, it came via TassyJim, who's pretty good on that sort of stuff. It's in a post somewhere & I think he said it's the XModem Checksum. Cheers Phil. Edit:- I Must have fiddled the print lines testing stuff; they don't match. |
||||
GoodToGo! Senior Member Joined: 23/04/2017 Location: AustraliaPosts: 188 |
@Captain Boing, I had two different pairs of Dumb RF modules here. The T/X module of one is appears kaput, and the R/X module of the other isn't much better. So I've only got one mixed pair that seem to work happily together. I might throw some more Aussie pesos at a few more seeing as they are so cheap. Thanks for the encryption link, interesting! @ Grogster, the UUUUUUUUUU's I got from one of your earlier posts. It works a treat. I tried between 10 and 15 before settling on 15 as effective. Expect me to pester you if I have trouble with the HC-12's..... @Phil, I like that checksum routine you posted, more neater and simpler solution to the crap one I came with, albeit along similar lines.... @drkl the modules are similar to this one Cheers! GTG! ...... Don't worry mate, it'll be GoodToGo! |
||||
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9083 |
Pester all you like. Happy to help if I can. Smoke makes things work. When the smoke gets out, it stops! |
||||
Print this page |