Computing stuff tied to the physical world

Pulling data from an EtherNode

In Software on Aug 17, 2010 at 00:01

Last month’s EtherNode sketch was an example of a simple web server which allows viewing incoming packets received by the RFM12B. Here’s a sample web page again:

Screen Shot 2010 07 13 at 231929

If JeeMon could access and pick up that data without requiring an extra JeeLink or JeeNode, then you could place the EtherNode wherever reception is best while running JeeMon on your desktop machine, or anywhere else.

In response to a request on the forum for just that, I started writing a little demo “application.tcl” for JeeMon to do this sort of web-scraping. Here’s what I came up with (code):

Screen Shot 2010 08 16 at 10.35.49

Sample console output:

Screen Shot 2010 08 16 at 10.42.48

The point here, is that it needs to periodically poll the EtherNode, get a web page from it, and skip the readings it has already seen before. That’s what most of the code in “EtherNodePull” does. Each packet that remains will be sent to the “GotPacket” proc, which just logs it on the console.

But that’s just one half of the required solution…

The bigger challenge is to also make JeeMon decode these packets, as if they came in through a serial USB link. There is quite a bit of logic in sketches/central/host.tcl to do that for a JeeNode or JeeLink running the “central” sketch (which is almost identical to RF12demo).

The reason this is more complicated, is that I want to be able to decode each packet in different ways, depending on the sketch running on the remote (sending) node. My network has more than just room nodes, and will be extended with many more node types in the future.

One workaround would be to collect all nodes of the same type in their own group, i.e. net group 1 for room nodes, net group 2 for the ookRelay, etc. And yes, that would work – but it’s not very convenient, and I’d need separate etherNodes to pick up the packets from each net group. Messy.

The approach I have used so far, is to maintain a config section for JeeMon, with information about the type of each node, organized by frequency band, net group, and node id:

Screen Shot 2010 08 16 at 10.52.23

It’s not automatic, but this way I just need to adjust one list whenever a new wireless node is brought online.

The current code in sketches/central/host.tcl is all about picking up packets, and mapping them thtough this configuration section to know what is what. It does this by setting up a pseudo “connection” whenever packets come in for the first time and includes logic to tear down this connection again when no new packets are received within a certain amount of time.

To use this approach with an EtherNode as data collection node, I need to re-factor the exisiting code and make the core mechanism independent of the Serial implementation. I also need to bring more of the code from central/host.tcl into the JeeMon code, so it can be re-used for EtherNodes.

Re-factoring is my middle name – I’ll update this post when the code changes are complete.

  1. It seems to me you have reached a point where it would make sense to implement some common low-overhead serialization format for how data is being reported by the JeeNodes, e.g. something like JSON or maybe OSC (http://opensoundcontrol.org/introduction-osc). If each JeeNode implemented a form of that, then they could even “talk to each other” without the need for a centralized JeeNode/JeeMon controller…

    • The format choice is no big deal. Each reading is usually just a few small numbers.

      Generating a JSON/OSC/XML (text) format on the remote node would lead to quite a bit of overhead in the RF packets and this ripples though in requiring more memory space for buffers, higher bandwidth use, more battery consumption, etc.

      The way I use JN’s right now, is that each remote node uses a format which is both very easy for it to produce and very compact to send across. The central “RF12demo” node just turns it into a generic text format to simplify processing on the receiving “normal computer” end. It doesn’t know about room nodes, but that means it also doesn’t need to be adapted/rebooted/re-loaded for any other (current or future) type of node.

      So the real question is where to put the “packet decoding” logic, which depends on the type and version of the source nodes. On a microprocessor, you’d have to do it all in C/C++. With dynamic languages, it seems to me that you can do it much more flexibly (such as supporting new node types and versions on a live system). That puts such logic on the PC, after the USB port, Ethernet card, etc.

      Can be done in any language of course. The data conversions are trivial. Managing the different types & versions of those little format converters is not quite as trivial, IMO.

      I may well be misinterpreting what you’re saying, but I don’t see how a downstream format choice solves the issue of turning a set of upstream reading types into that chosen format.

Comments are closed.