 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 : Detecting RXD without RSSI....
| Author | Message | ||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
Hi all. 
I'm looking for a way to detect when there is serial present on a line at any given instant. The concept behind this, is to know if there is any activity going on on a wireless link, by monitoring the RXD line of the RF module for any activity, so that if a module wants to talk, it can look and see if there is already activity BEFORE it makes any attempt to hop onto the frequency and send it's data. First thought was the serial native serial ports, but as they are buffered, this won't work, as I need to know if there is activity on the network BEFORE trying to transmit a new message, or I will generate a heterodyne and you'll get nothing. The system is multi-point to point, so there is one base unit, and several perimeter transmitting nodes. Past the serial ports, my thoughts hovered around the 7555 timer in monostable mode: 
The idea behind THAT circuit, was that the serial stream from the RXD pin of the RF module is coupled to the 7555 timer via a 10k resistor, and for any given low-going pulse in the data-stream, the 7555 output will go high for the minimum time set by the RC timing components. All that is fine in theory, but I don't have any 7555's to play with, so can't bench test this idea. I plan to get some, but for right now.... I can then monitor the 7555 output via a MM pin, and simply wait for that to go low again, pause, check it again, and if still low, hop onto the network and send the message. There will be about four or five transmit nodes in the network, and the entire idea behind all of this, is essentially to prevent data collision when two or more nodes try to transmit at the same time. Can anyone suggest any other method of doing this? The RF modules will be the HC-12's, but they don't have a RSSI pin to tap into, so I need to think of some other way. 555's(or 7555's) are cheap as chips, so this is probably a nice cheap way to do it, but open to other suggestions or ideas. Smoke makes things work. When the smoke gets out, it stops! |
||||
| HankR Senior Member  Joined: 02/01/2015 Location: United StatesPosts: 209 |
Grogs, What you're doing is often called pulse stretching, but it's not at all necessary. The MM looking for a minimum time in the idle state, all the while checking for a change to a non-idle state, will do the same thing. Bear in mind I don't think there is any way to avoid signal collisions using this method of watching for the state of RX activity, no matter how you implement that function, it just makes them less likely. Hank |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
Do you have any alternative suggestions to avoid signal collisions? I could also look into having some acknowledge bytes sent back to the node from the base. If the node does not get these acknowledge bytes back, it tries resending the message till it does. In the case of a heterodyne, the node would not receive the acknowledge bytes, so would wait a little, and try again when it was more likely to have success. The heterodyne could corrupt both the message and the acknowledge, but if it did not get the acknowledge, then it resends the entire message till it does get back the acknowledge. I wonder if that is worth trying..... Any other members, feel free to chime in with your thoughts or suggestions. Smoke makes things work. When the smoke gets out, it stops! |
||||
| WhiteWizzard Guru  Joined: 05/04/2013 Location: United KingdomPosts: 2794 |
Hi Grogs, You say that your requirement is to avoid data collisions from your multiple transmitters. This is a very similar problem with RFID tags for which I spent years consulting about (including talking about this very thing). Questions: how often are the Transmissions? And what duration is a typical message? Are all messages similar length/time? Are messages from a single Transmitter at regular intervals, or could they be at 'random' times depending upon a 'local' condition. If dependent, how soon after the 'event' does the base station need to know about the event? And a big thing, is it one way comms or does the base station need to 'reply' back to the transmitter(s)? Depending on the answers to these questions, there are several approaches. One to consider is 'time-slicing' the transmissions between the transmitters. Another is to use the base station to request if any data is available from transmitter x, and if so wait for the data. The important thing to remember is that each method has pro's and con's. So the ideal solution depends on the above questions. Will keep a keen eye on this thread - it is already bringing back many memories now  . . . .
WW For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
- Transmissions at random, controlled by 'Local events', which can happen at any time. - Duration is less then a second, probably half a second or even less - the message is only 15 bytes long. - Messages can be from any transmitter, at any time. - Base does not care how long it takes for message to arrive(within reason). Only one way, unless I implement the acknowledge reply idea(probably not). Now there's an idea. 
As there is only 5 or 10 nodes, I could create a transmission map, and assign each node to a certain time period - simple delays that are different periods for each node would probably do the job. EDIT: No, that won't help either.  Nice idea though. It won't work, cos if you space the nodes out by 500mS each, as the nodes transmit at random triggeded by local events to that node, the delays could actually generate collisions if the timing was against you. Oh well - nice idea while that lasted.
Yes, that is another method. EDIT: This is now the method I am looking into, as then the base can control everything, including polling the nodes for anything to report. That should avoid collisions, as the base would only ask any ONE node for a transmission at any one point in time, weather that be data, or just a 'No, I don't need to tell you anything' kind of NUL response or something. Each node can just buffer any data to send, till the base polls that node - that is easy enough to code. That method results in a slight delay between the base polling the nodes, and getting any reply, but that is no problem, and each node can then be self-buffering, so to speak. Thanks for the ideas - that is probably a more sensible method, then trying to detect data with the 7555. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Bizzie Senior Member Joined: 06/07/2014 Location: AustraliaPosts: 185 |
This may be a bit off subject but what about using something like "Dorji DRF1110N20N 433MHZ 20dBm Mesh Network Module". I know it is more expensive but all the work seems to be done for you. The Wiltronics price is $24.30 each but I am sure a cheaper source could be found. I am considering them for a rain gauge network over our "farm" (More the area we contract in). Rob White |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
Yeah, I have been looking at other modules like that too. More expensive, yes, but as you say - all that is done for you, nativly, by the module itself. Something to be said for that. 
I am currently looking at playing with the Sunray RF 1E86 MESH module. It's not on their website, but I have some here, and have the PDF. If anyone is interested, I can put up a link to the PDF. 
They too are about the same US$25 each, from what I remember when I bought some. I sorta liked the idea of using the cheaper modules though, but then, the cheapest methods are often far from the best. By the same token, the most expensive is not necessarily the best either!  Smoke makes things work. When the smoke gets out, it stops! |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1098 |
G, Have look nRF24L01+ at http://www.nordicsemi.com/eng/Products/2.4GHz-RF/nRF24L01P Also, if you just do a Google search on nRF24L01 you will see the Sparkfun site with a pdf of the specs. In particular, section 7.7 of the pdf that's shows 6 transmitters back to a central receiver with full protocol management to handle error checking, message acknowledge, collision management etc. These can be had for a few bucks each on ebay. I am working on an example project and will post when I get further down the track. Cheers, panky ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
Cheers, will check them out.
They are certainly cheap enough - so cheap, in fact, that I might get a few just for the sake of playing about. They only have 3mW output power @ 2.4GHz, so their range would be pretty tiny, BUT if they do work in MESH(or equivalent), then so long as they are all in range of each other, no problem. Smoke makes things work. When the smoke gets out, it stops! |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5914 |
Base sends an ACK when the random data arrives (or NAK if data without valid checksum arrives) If no ACK or if NAK reply recieved, outstation resends. Each outstation has a different wait timer set so that if two outstations sent with a collision the first time, there will be different times to the retransmission hence no collision. Instead of the 555 circuit, you could count the pulses. No pulses in one second = no serial activity. Jim VK7JH MMedit MMBasic Help |
||||
OA47 Guru Joined: 11/04/2012 Location: AustraliaPosts: 911 |
Grogs, I had a similar dilemma with a past project where each of 20 units were to report data back to a central location on the same carrier frequency. I used the following sequences from the micromites. Field unit has new data...... FIELD UNIT MASTER UNIT SEND REQUEST TO MASTER WITH UNIT NUMBER --------> RX REQUEST RECEIVE ACK <-------------------- SEND ACK WAIT IF ACK NOT RXD IF DATA NOT RXD AFTER .5SEC SEND ACK SEND DATA -----------------------------------> WAIT UNTIL DATA RECIEVED RECEIVE ACK <------------------------------------SEND ACK IF ALL DATA WORDS NOT RECEIVED THEN LOG ERROR ELSE WAIT FOR NEXT REQUEST FROM FIELD UNITS GM |
||||
 Print this page |
