 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 : How do HC-12’s Work?
| Author | Message | ||||
| Phil23 Guru  Joined: 27/03/2016 Location: AustraliaPosts: 1667 |
Hi all, Wondering if a few can elaborate on what goes on behind the scenes. So "ABC" hits the TTL port, what from there? Does the data then get encoded with some checksum or similar before it's punched out into the air as a packet of data? Similarly, what happens at the other end? Is it a case of here's a packet, lets decode it & see if it's any good? And if so pass it out the TTL port? Cheers Phil |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1114 |
Phil, From my reading, there does not appear to be any great control of packetisation in the HC-12. As far as I can see, the HC-12 uses the Silicon Labs Si4464 chip to handle the actual radio communications. It can optionally operate in a variety of FSK (frequency shift keying) or OOK (on/off keying) modes for the type of modulation of the radio transmission. It can also control the format of the transmission from direct, with just a synchronising pre-amble before the asynchronous data transmission (in fact, this appears to be the method used in the HC-12). It also has a full packet mode with inbuilt control of packet length, cyclic redundancy and other packet management features. Unfortunately, this packet format does not appear to be supported in the HC-12. If you need full packet control and management ancd error checking, then something like the Nordic nRF24L01 module is worth a look - quite a deal more complex but equally much more powerfull and fully networkable. Cheers, Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
| Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1667 |
Hi Doug, So does this mean the two modules synchronise & handshake before data is exchanged, & hence more than 2 devices on the same channel will cause issues? Phil |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9590 |
Generally speaking, all RF modules from cheap to expensive will ALL cause data-collisions if two or more modules attempt to transmit at the same time. This usually results in an heterodyne where both transmitters hit each other's transmission, and the result is just a garbled mess that the receiver will totally ignore. There are various ways of preventing that, from stuff as simple as having each node setup so it can only transmit within it's window of any pre-detirmined packet size, to use of RSSI(Received Signal Strength Indicator) lines(if the module has one) to detect if there is already something being transmitted and to hold off, right up to the full MESH networked modules that handle everything for you. I hear good things about the XRF modules, which are essentially Xbee clones at less then half the price of the genuine Xbee units, but supporting full MESH networking, you can squirt data out to them whenever you like, and the network of modules will look after routing and data-collisions etc all for you which makes them very easy indeed to use. The practical downside of that idea, is that it is usually much more expensive per-module to use a MESH network(original Xbee's were $70 a module!) if you have more then a couple of modules. How many nodes are you trying to deal with? Smoke makes things work. When the smoke gets out, it stops! |
||||
| panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1114 |
Phil, The HC-12 can be set to multiple channels however, at any one time, only 2 modules can be on the same channel. If you want multiple links, have the master module select a channel then talk to one slave then switch the master to another channel and talk to another slave on a different channel. This would be in a round robin arrangement of talking to multiple slaves. Cheers, Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
| Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1667 |
3 to 4 Maximum. One a Master, the other 2 or 3 Slaves [Quote] Generally speaking, all RF modules will ALL cause data-collisions if two or more modules attempt to transmit at the same time. There are various ways of preventing that, from stuff as simple as having each node setup so it can only transmit within it's window..... [/quote] That was my logic I have in mind, separate time windows, Managed from the Master end, essentially polling the slaves in a manner that only the requested one would respond. IE:- [Code] "Slave1 Please send data", etc[/code] So as long as there is no low level responses. That's why I started the tread, to try & find out if anything like that goes on. Am I correct in presuming it doesn't? As in when the master transmits data, the slaves will remain RF silent, no behind the scenes transmissions to acknowledge a connection. I have 2 connected at the moment, & 2 more I haven't had a chance to add a 3rd yet. Cheers. |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6269 |
As well as other modules transmitting at the 'wrong' time, you have to cater for car remotes, garage door openers weather station remote sensors etc. That's only the devices using the same frequency. You can also have problems with strong signals on other frequencies. UHF CB radios are likely to overload the inputs. My weather station stops receiving outside data (on 433MHz) when I transmit on 147MHz due to it's third harmonic. With RF, there is always the chance of corrupted data. You need some sort of addressing scheme (so the receiver knows that the packet is for them) and some sort of checksum/CRC so the receiver knows that the data is valid. Optionally, some sort of acknowledge reply or request to resend when packets are lost. If the master is requesting the data, a simple re-request of no reply within set time would do. As long as it knows to resend the old data and not the next set. Jim VK7JH MMedit |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9590 |
Well, presumptions and assumptions are the mother of all.......well, I am sure you are familiar with the rest of that saying.  
You'd need to download the PDF's for the chips used on the HC-12 modules, and have a read to establish exactly what is going on. Grabbing an HC-12 I have here and having a quick look, they use an ST MCU to handle the data, and the tiny little QFN chip is the actual radio modem. You'd need to do some reading on the radio one, but unfortunately, there is little you can do to know exactly how the code running on the ST MCU is doing it's thing. There could well be other low-level acknowledge transmissions etc - I would not be surprised. Perhaps don't over-analyse the problem. While data collisions etc can happen, they don't generally prove to be THAT much of a problem, if you write your code correctly. I use retries. More-or-less along the same lines as you have already said above with the "Slave 1 please send data" idea. The process in pseudo-code would be: START: DO Transmit request to Slave #1 Do 'Start time-out counter Increment timer Check buffer for data If data present then exit do If timer>=pre-set then set a flag and exit do Loop If flag is set then time-out occurred so goto START and request data again Suck data out of buffer 'Flag NOT set and loop ended Do your data things with data received Loop This is VERY simplistic, but shows you ONE way(and only one way) that you can deal with loss of data through re-tries. In the example above, lets assume there is no other radio traffic, and the message gets through to the slave fine. The slave will respond, the data will go into the serial port buffer, and the code will detect that and have data to play with right away. In the event that there is a data-collision(of any kind), then the request for the data will FAIL, and so then the DO/LOOP will exit after a pre-determined time in which the slave is required to respond. If that happens, the DO/LOOP exits with a flag set, and if the flag is set when the loop exits, the code knows that the slave DID NOT respond, so it sends the request again. This should work fine, although I have not actually tested it. The theory is sound for basic stuff though, and the upshot of the pseudo-code is that if the master will follow these steps: 1) Request data 2) If I got it, goto step 4 3) If I did not get it and times up, then got step 1 and try again 4) Process data Others will come up with much more advanced methods, but I still like and use the KISS approach. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1667 |
|
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
