Alain

Recent activity

Posted in extra byte in ChannelUpdateEvent (9)

No apologies needed. All questions are helpful. We added a few words and a drawing to clarify the documentation.

So the .nocand/cache file is just a JSON file that keeps track of the correspondence between the board's unique identifier UDID and the assigned node NID, across sessions:

  • The UDID is 8 bytes and unique across all NoCAN boards
  • The NID is between 1 and 127 and is only unique within a network.

Typically, if you plug a new device in you network, it gets a NID corresponding to the first available free NID not in the cache. If you have only 2 nodes, NID 1 and NID 2, the next one will get NID 3 (incremental). If you unplug node 1, and plug a new node, that new node will get NID 4, and if you plug back the first node, it will get NID 1. All this is done more for convenience purposes.

Have you considered using the UDID as a reference point instead of the NID?

Edit: you can get the UDID on the CANZERO with the library function Nocan.getUniqueDeviceIdentifier:
https://www.omzlo.com/articles/the-nocan-api#nocan-getuniquedeviceidentifier

Posted in extra byte in ChannelUpdateEvent (9)

The way events are encoded is defined in https://omzlo.github.io/nocan/nocan-event-protocol.html#event-packets
But basically, events are encoded as:

  • An event Id (1 byte)
  • The event value length (1 to 5 bytes)
  • Event value

The event value itself will have a structure that depends on the event id. If the event Id is 9, the encoding of the Event data is specified in the subsection titled ChannelUpdateEvent (9) described at
https://omzlo.github.io/nocan/nocan-event-protocol.html#channelupdateevent-9

Posted in extra byte in ChannelUpdateEvent (9)

Hi James,

I'm probably missing a bit of context on the Python side, but what you printed in hex looks a lot like a ChannelUpdateEvent message, except that the first byte (09) is missing. If you break down 1c010003025753150239343220303030303236383736373739000062fd you get:

1c -> 28, the number of bytes that follow

01 -> It's a channel update

0003 -> the update concerns channel 3

02 5753 -> The channel name is 2 bytes long and reads as "WS"

15 0239343220303030303236383736373739000062fd -> the channel data is 21 bytes, and contains the value 0239343220303030303236383736373739000062fd

By applying data = s.recv(BUFFER_SIZE).strip() you almost certainly removed the leading byte 0x09, which happens to be a tab is ascii as well, and therefore a whitespace that is removed by strip().

Once you add the leading 09 to the message, it seems to me as a fully consistent ChannelUpdateEvent message as defined in https://omzlo.github.io/nocan/nocan-event-protocol.html

Alain

Posted in PiVoyager

Mark,
Thanks for the info and for mentioning our work to Sparkfun! :-)
I'm building 4 prototypes and I'd be happy to send you one by the end of next week to get your feedback. Please send your contact details at support@omzlo.com for the shipment.
Note that it will come without a battery. Let me know if your want a 40 pin GPIO header soldered to the board as well, or if you prefer to solder one yourself.
These prototypes will look like this and should represent the final iteration of the design:

Cheers,
Alain