Real time application development for BBB

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.

Why real-time when temperature won’t change that quickly?

Regards,
John

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.

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 ?

CC2531 is a wireless transceiver for 6LowPan or ZigBee network.

Regards,
John

On Tue, 14 Feb 2017 21:49:52 -0800 (PST), avni gupta
<avnigupta018@gmail.com> declaimed the
following:

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.

  CC2531 is technically a SoC /chip/... When you say "USB dongle" are you
referring to the CC2531EMK (evaluation module kit
CC2531EMK Daughter card | TI.com )? 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.

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.

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.

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.

On Wed, 15 Feb 2017 19:58:04 -0800 (PST), avni gupta
<avnigupta018@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.

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

The CC2531 won’t withstand the high levels of EMC when the switchgear trips.

Regards,
John

On Wed, 15 Feb 2017 19:58:04 -0800 (PST), avni gupta
<avnigupta018@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.

With IEEE802.15.4, you can reserve certain time slots so there is no collision.

Regards,
John

On Thu, 16 Feb 2017 20:47:23 -0800, John Syne
<john3909@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?)

On Thu, 16 Feb 2017 20:47:23 -0800, John Syne
<john3909@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?)

This is done via the standard API. No configuration required.

Regards,
John

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.

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