Real time application development for BBB
96 views
Skip to first unread message
avni gupta
Feb 15, 2017, 8:20:29 AM2/15/17
to BeagleBoard
I am masters student, doing my internship. I want to work on beaglebone black (BBB) and develop a real time application such that the data generated from number of sensor nodes comes to sink node, which is connected to USB of BBB. How do i proceed? The sensor nodes are temperature sensor and the sink is Texas Instrument's (TI) CC2531 USB dongle (works on ZigBee Green Power). What OS, what application should i start working on. Please help.
John Syne
Feb 15, 2017, 11:40:15 AM2/15/17
to beagl...@googlegroups.com
Why real-time when temperature won’t change that quickly?
Regards,
John
On Feb 14, 2017, at 9:49 PM, avni gupta <avnigu...@gmail.com> wrote:
I am masters student, doing my internship. I want to work on beaglebone black (BBB) and develop a real time application such that the data generated from number of sensor nodes comes to sink node, which is connected to USB of BBB. How do i proceed? The sensor nodes are temperature sensor and the sink is Texas Instrument's (TI) CC2531 USB dongle (works on ZigBee Green Power). What OS, what application should i start working on. Please help.
--
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 beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/5b6d3cfd-cbaa-44da-8e5b-27cb759e7d27%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
TJF
Feb 15, 2017, 3:00:50 PM2/15/17
to BeagleBoard
Use Debian OS, version 3.8 is most reliable.
Why additional hardware (TI-CC2531)? When your temperature is in the range of -50 to 125 °C you can use Dallas sensors. Connect a bunch of them directly to a GPIO line of the BBB (a 4k7 pull-up is all you have to add).
Regards.
Why additional hardware (TI-CC2531)? When your temperature is in the range of -50 to 125 °C you can use Dallas sensors. Connect a bunch of them directly to a GPIO line of the BBB (a 4k7 pull-up is all you have to add).
Regards.
William Hermans
Feb 15, 2017, 3:34:33 PM2/15/17
to beagl...@googlegroups.com
I concur. I'm using a DS18B20 here, and I'm having a hard time seeing how it could have been easier to setup, and read from. You know, from an embedded project perspective. I did not have to add a pullup, ut I'm also only using one sensor. Maybe multiple on the same data channel needs this ?
John Syne
Feb 15, 2017, 3:55:22 PM2/15/17
to beagl...@googlegroups.com
CC2531 is a wireless transceiver for 6LowPan or ZigBee network.
Regards,
John
--
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 beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/5de23a5c-a575-45b3-8595-d1a93f010bb0%40googlegroups.com.
Dennis Lee Bieber
Feb 15, 2017, 8:49:19 PM2/15/17
to beagl...@googlegroups.com
On Tue, 14 Feb 2017 21:49:52 -0800 (PST), avni gupta
<avnigu...@gmail.com> declaimed the
following:
CC2531 is technically a SoC /chip/... When you say "USB dongle" are you
referring to the CC2531EMK (evaluation module kit
http://www.ti.com/tool/CC2531emk )? Based upon the documentation, that
dongle is programmed to act as a packet sniffer -- to program the dongle
for other uses you require a compatible programmer (it apparently can not
be programmed over the USB connection). Do you have such a programmer? BTW
-- it apparently uses an 8051 type microcontroller (interesting that TI is
using an Intel-originated MCU, even if it is a clone TI makes).
Since you are talking an RF module, I presume the sensors are
remote/stand-alone wireless units. Unless packet sniffing is sufficient,
you likely will have to program the dongle to act as a data collector for
the sensors. You'll also have to program it to act as a USB serial port
(that's likely the easiest way to transfer the collected data to the BBB --
I'm presuming Debian has drivers for virtual COM ports [to use Windows
terms])
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. Fancier might use bi-directional control, where the BBB asks for
specific sensors, and the dongle returns the reading for those sensors.
Heck, if the transfer is done in formatted ASCII, any "terminal" program
(minicom) would support manual testing of the dongle, before writing an
actual BBB application.
The protocol between the sensors and the dongle I have no knowledge of.
You'll have to program the dongle to handle that side too. The firmware
library may have library functions for those.
--
Wulfraed Dennis Lee Bieber AF6VN
wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.com/
<avnigu...@gmail.com> declaimed the
following:
referring to the CC2531EMK (evaluation module kit
http://www.ti.com/tool/CC2531emk )? Based upon the documentation, that
dongle is programmed to act as a packet sniffer -- to program the dongle
for other uses you require a compatible programmer (it apparently can not
be programmed over the USB connection). Do you have such a programmer? BTW
-- it apparently uses an 8051 type microcontroller (interesting that TI is
using an Intel-originated MCU, even if it is a clone TI makes).
Since you are talking an RF module, I presume the sensors are
remote/stand-alone wireless units. Unless packet sniffing is sufficient,
you likely will have to program the dongle to act as a data collector for
the sensors. You'll also have to program it to act as a USB serial port
(that's likely the easiest way to transfer the collected data to the BBB --
I'm presuming Debian has drivers for virtual COM ports [to use Windows
terms])
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. Fancier might use bi-directional control, where the BBB asks for
specific sensors, and the dongle returns the reading for those sensors.
Heck, if the transfer is done in formatted ASCII, any "terminal" program
(minicom) would support manual testing of the dongle, before writing an
actual BBB application.
The protocol between the sensors and the dongle I have no knowledge of.
You'll have to program the dongle to handle that side too. The firmware
library may have library functions for those.
--
Wulfraed Dennis Lee Bieber AF6VN
wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.com/
avni gupta
Feb 15, 2017, 10:40:09 PM2/15/17
to BeagleBoard
Hi John,
I have to develop a real time temperature monitoring system for switchgear, where temperature changes and needs to be monitored for complete operation of the switchgear.
avni gupta
Feb 15, 2017, 10:45:27 PM2/15/17
to BeagleBoard
Hi TJF,
I am restricted to use CC2531 USB dongle as the ZigBee receiver for temperature sensor. These sensors are placed on switchgear and send data to CC2531 wirelessly. This data is further required to be collected and analysed through BBB real time application.
avni gupta
Feb 15, 2017, 10:58:04 PM2/15/17
to BeagleBoard, wlf...@ix.netcom.com
Hi Dennis,
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.
Dennis Lee Bieber
Feb 16, 2017, 9:12:31 AM2/16/17
to beagl...@googlegroups.com
On Wed, 15 Feb 2017 19:58:04 -0800 (PST), avni gupta
<avnigu...@gmail.com> 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.
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.
<avnigu...@gmail.com> 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.
>
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.
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.
John Syne
Feb 16, 2017, 11:41:36 PM2/16/17
to beagl...@googlegroups.com
Again, switchgear is large and won’t change temperature in milliseconds, so I don’t understand why you need real-time temperature monitoring. Are you measuring the arc temperature before extinguishing?
Regards,
John
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/11db1952-5ebe-45c1-969e-6953c5017162%40googlegroups.com.
John Syne
Feb 16, 2017, 11:43:26 PM2/16/17
to beagl...@googlegroups.com
The CC2531 won’t withstand the high levels of EMC when the switchgear trips.
Regards,
John
--
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 beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/b9a2ce43-38dc-4a11-afee-c7edf2fb305d%40googlegroups.com.
John Syne
Feb 16, 2017, 11:47:41 PM2/16/17
to beagl...@googlegroups.com
Regards,
John
> --
> 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 beagleboard...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/7mabacp87hncngci20nph40o8eocqegblj%404ax.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 beagleboard...@googlegroups.com.
Dennis Lee Bieber
Feb 17, 2017, 7:28:42 AM2/17/17
to beagl...@googlegroups.com
On Thu, 16 Feb 2017 20:47:23 -0800, John Syne
<john...@gmail.com> declaimed the following:
>With IEEE802.15.4, you can reserve certain time slots so there is no collision.
The OP stated they are using the dongle in default packet sniffing mode
(a passive mode, I believe) -- by which I understood there is no
configuration of, or interaction with, the sensors being performed. So, no
reservations unless some other unit is controlling them (in which case, why
the packet sniffer?)
<john...@gmail.com> declaimed the following:
>With IEEE802.15.4, you can reserve certain time slots so there is no collision.
(a passive mode, I believe) -- by which I understood there is no
configuration of, or interaction with, the sensors being performed. So, no
reservations unless some other unit is controlling them (in which case, why
the packet sniffer?)
John Syne
Feb 17, 2017, 10:26:12 AM2/17/17
to beagl...@googlegroups.com
> On Feb 17, 2017, at 4:25 AM, Dennis Lee Bieber <wlf...@ix.netcom.com> wrote:
>
> On Thu, 16 Feb 2017 20:47:23 -0800, John Syne
> <john...@gmail.com> declaimed the following:
>
>
>> With IEEE802.15.4, you can reserve certain time slots so there is no collision.
>
> The OP stated they are using the dongle in default packet sniffing mode
> (a passive mode, I believe) -- by which I understood there is no
> configuration of, or interaction with, the sensors being performed. So, no
> reservations unless some other unit is controlling them (in which case, why
> the packet sniffer?)
Regards,
John
> --
> 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 beagleboard...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/oiqdac9dsqv37pkbc63cscmbfrhif7krh7%404ax.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 beagleboard...@googlegroups.com.
avni gupta
Mar 2, 2017, 5:51:25 AM3/2/17
to BeagleBoard
Yes, the temperature won't change in milliseconds. But continuous monitoring is required for understanding the trend of failures. The temperatures at busbar and cable joints needs to be monitored.
John Syne
Mar 2, 2017, 9:46:21 AM3/2/17
to beagl...@googlegroups.com
So that tells me you need to stream the temperature measurements, which is what the AM335x ADC IIO driver does. Currently the driver is sampling at 800 ksps, but you can modify the sampling rate in the ADC overlay.
Regards,
John
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/543299fb-f850-4848-88b8-5ecfb98cf6aa%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages