> On Feb 16, 2017, at 6:12 AM, Dennis Lee Bieber <[email protected]> wrote: > > On Wed, 15 Feb 2017 19:58:04 -0800 (PST), avni gupta > <[email protected]> declaimed the > following: > >> The dongle is programmed to act as a packet sniffer, which is required for >> the application. So, I need not to program the dongle. >> Yes, the sensors are remote/ stand-alone wireless units, communicating >> through ZigBee. Packet sniffing is sufficient, the dongle is able to >> collect the data from sensors. I need to connect this dongle with BBB and >> get the data from this receiver and display it in a real time application. >> >> " The BBB probably doesn't need any "real-time" software; just an I/O >> loop reading the dongle "COM port" for the data stream collected by the >> dongle. " I don't understand this completely? Please guide me further on >> this. >> > > "Real-time" applications typically have firm deadlines -- if something > doesn't happen in x time-units, sound an alarm, reboot, etc. > > But if you are using the dongle in packet-sniffing mode you are totally > passive and only get data whenever the dongle detects a packet (and you > might get packets that have nothing to do with your sensors). You have no > control over how often you receive packets nor how many sensors you receive > them from (if someone moves another sensor into range of your receiver it > will capture packets from it too). I don't know how the sensors handle > transmit collisions -- if at all... Maybe they just broadcast on a > semi-random time delay -- if two or more choose to transmit at the same > time, your sniffer may just see garbage. If they are smarter, they will > only attempt to transmit when they don't detect activity on the channel. > With a passive sniffer, there is no return signal to the sensors that says > "I received your data". That means the sensors just blindly transmit > over&over. With IEEE802.15.4, you can reserve certain time slots so there is no collision.
Regards, John > > I presume the sensors provide some sort of unique ID (otherwise you > don't even have a way to tell them apart). > > So, in the end, while you may have an event driven application, it > falls short of being a real-time application. The events being receipt of a > packet from the sniffer. Without a packet, your application does nothing. > When a packet is captured you can decode it and update a display or do > something else with it, but that is about it. So to get back to the "loop" > statement your main application ends up looking like: > > loop forever > wait for packet from dongle > update display or other status > end loop > > I suppose you could put some sort of time-out on the "wait for packet" > to allow the "update display" to do some housekeeping operations -- if you > have a list of sensor IDs you could perhaps check for > time-since-last-update and put a marker on the display if you've not > received a packet from a sensor in some configured time period. I'd > probably try a threaded approach -- one thread just waiting for packets > from the dongle, when it receives a packet it adds it to a queue; the other > thread would be a timed update loop... > > T1: loop forever > wait for packet from dongle > add packet to process queue > end loop > > T2: loop forever > sleep until TimeUpdate > qlen = length of queue > for i in qlen > process packet from queue > for i in IDList #presumes fixed list of sensors > if TimeUpdate - sensor(i).time > maxTime > set OverDue status > update display with sensor(i) > TimeUpdate = TimeUpdate + processInterval > end loop > > The reason for capturing the queue length and looping over just that many, > rather than looping until the queue is empty is that you might be getting > just enough new packets to run over the processInterval duration. Instead, > at the start of each update cycle, you only process the packets that had > been queued up to that moment. That update loop is the closest thing you > have to real-time, and I suspect it's going to be on the order of once per > second... Nothing like having to respond to data in less than a > millisecond. > -- > Wulfraed Dennis Lee Bieber AF6VN > [email protected] HTTP://wlfraed.home.netcom.com/ > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/7mabacp87hncngci20nph40o8eocqegblj%404ax.com. > For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/9E704896-4DCE-4DB8-B682-4428B165406E%40gmail.com. For more options, visit https://groups.google.com/d/optout.
