The work on VSCP continues. And in the upcoming months the modules Grodans Paradis AB sells in the VCSP shop will be available again as chips now finally gets available again. They will be accompanied by a few new products also this spring. CAN4VSCP <-> Wifi and some others. Note that this is not CAN <-> Wifi, Even if it can be used for that to. I will concentrate on VSCP for my stuff and will leave the arena of pure CAN to others.
I work on two main tracks at the moment. One track is the new VSCP Works which has been put aside for some time now but will be taken care of later this spring again. The other track is the VSCP Droplet protocol. This has been a thing in my head for many years now but as I am doing a HAN P1 module for smart power meters and needed firmware for it I decided on realizing this track after looking at a lot of other possibilities like ESP-Now and BLE mesh. They are all so damn bloated and I like KISS (Keep It Simple Stupid).
The Espressif chips have a “protocol” called ESP-Now. This is based om a custom IEEE 802.11 frame format and can do broadcasting and addressed frames. I went ahead on this row just to discover that there was some heavy security flaws in the implementation. For one the IV was not generated new for each frame but only once. This will probably be fixed, but it left me in the dirt.
I decided to do the droplet protocol but use the lower parts of ESP-Now to make it simpler to implement (it is by no means locked to Espressif chips). This is using the broadcast mode in ESP-Now which is actually only a Wifi driver set in promiscuous mode using a custom frame. But by going this path it was a lot more work to do of course. But now I am working my way along that trail anyway. Does not everything turn out to be a lot of work in the end…
I have’t written any comprehensive documentation for VSCP Droplet yet but want to share some small info about it here.
VSCP Droplet has three types of nodes. Levels if you like. They all talk VSCP Level II and implement the read/write registers, have an MDF, is OTA updatable, and can have it’s own decision matrix.
Alpha nodes all have Wifi access. They are provisioned with BLE (or access point). They can be OTA updated. They can OTA update Beta and Gamma nodes. They can add Beta or Gamma nodes to a network that is defined by a channel and a 32 byte primary key. All traffic except for a few events like heart beats) are encrypted with AES-128 (192/256) or unencrypted if one like. An alpha node is always powered.
Beta nodes does not have Wifi and communicate only with the VSCP droplet protocol. They are provisioned by an Alpha node by setting it in initialization mode with an init button and in this state it starts to send frequent heartbeats on each channel until it get the primary key from an Alpha node. The Alpha node need to know the MAC address and the Local 32 bit unique key of the node do do this. When they get the network private key they become part of the network and can do there designed job. A Beta node is always powered.
Gamma nodes can be provisioned in the same way as Beta nodes and be done so by an Alpha or a Beta node. Beta nodes are in all aspects the same as Gamma nodes except they can go t sleep and only wake up occasionally. Typically be battery powered. Alpha and Beta nodes can act as mailboxes that hold events that are intended for a Gamma node and from which the gamma node can fetch events when it wakes up.
Traffic on the network is based on managed broadcast. All frames not seen in near time (a cache keeps track of newly seen noes) buy a node is transmitted until the ttl of the frame has expired. RSSI can be used also to limit this re transmit. Think the hole network as a lake when a rain starts. Drops creating waves that propagate and fill the hole lake. VSCP has small messages and low bandwidth and it should work for most VSCP implementations. The problem of course being that each events on the network generate a lot of traffic for a short time and it is essential to keep the event rate down. Something that be tweaked by setting s lower value for ttl and higher demand for rssi.
All and all this gives nodes that can work over long ranges with high response times. I have tested here and it is no problem to reach all corners of my house (~500m2) with one or at most two hops.
I am now working with the beat-node functionality with most of the alpha-node functionality in place. Maybe there can be some early releases of this before the summer. But beware it is still possible that I have to kill this track as it is still very experimental. No promisses.
But it is definitely KISS. And that is perfect on a day like this one.
I will try to post some shorter updates on what is happening as I move on this track… It is terribly fun work anyway and I enjoy it very much. It is probably stupid to continue to develop this project dubbed VSCP. But I sort of got used to do so on a day to day basis. Who needs users? 🙂
Have fun!