The VSCP developers blog

The VSCP daemon now is in it’s of repository https://github.com/grodansparadis/vscp-daemon . The VSCP repository will be streamlined to hold common code that will server other parts and also keep general discussions and wiki.

The structures in vscp.h for events now is typedefed as vscp_event_t and vscp_event_ex_t. The old vscpEvent and vscpEventEx is still available for backward compatibility.

Also

vscpEventFilter has change to vscp_event_filter_t

VSCPStatistics to vscp_statistics_t

and

VSCPStatus to vscp_status_t

Old typedefs are still available for compatibility with legacy code.

The 64-bit nano second timestamp is now introduced for VSCP. This is what we often call a Unix timestamp with nano second resolution and which holds the number of nanoseconds since the epoch (January 1, 1970, 00:00:00 UTC).

The “old” format with separate bytes for year, month, day, hour, minute, second and a 32-bit microsecond timestamp was constructed that way to make it easy for very low-end devices to receive/send time information. This is still possible as the format is preserved. But the new format will be promoted.

Note that it is still possible to send a microsecond timestamp for devices that rely on it. Just multiply the value with 1000 and set it to timestamp_ns. Relative timestamps can easily still be used.

Two header bits 9/8 specify the frame format. They were originally set to 0b00 and would with the new format be set to 0b01. So when a new event is constructed they shoudl be set. The define VSCP_HEADER16_FRAME_VERSION_UNIX_NS in vscp.h does that. Priority is probably also bits that should be altered usually to VSCP_PRIORITY_NORMAL

Helpers to convert between the two formats are available in the helper library and in vscphelper.cpp and vscp-firmware-helper.c. They are

int64_t
vscp_fwhlp_to_unix_ns(int year, int month, int day, int hour, int minute, int second, uint32_t microsecond);

and

void
vscp_fwhlp_from_unix_ns(int64_t unix_ns,
int *year,
int *month,
int *day,
int *hour,
int *minute,
int *second,
uint32_t *microsecond);

year and month is still available in the event defines also if nanosecond timestamps are used. This to preserve the size of frames. It is recommended to set year=0xffff and month=0xff when the new timestamp is used. Still the frame versin bits in the header is the main detection to use for frame type.

Binary frames have been around for a long time now. MQTT, UDP and Multicast transport uses them. In the current project I work with, a CAN4VSCP <-> wireless gateway I have finally realized that TLS/SSL is not the perfect solution for an embedded server device. The reason is that certificates need to be updated on a regular basis. This is easy to handle on a pc based higher end solution but very much not so on a remote device. So what to do?

My solution to this problem is to generalize the binary protocol and use it also (as an option) in websockets and tcp/ip. This gives a communication path that allows for secure AES-128/192/256 encryption on all transports supported by VSCP.

With the addition/change of the nanosecond timestamp the frame format is changed to support this. The old frame is still available though. But all conversions in the helper libraries. will convert the format to the newer frame type.

There is also two new packet types (defined in the high nibble of the first byte of the frames).

The first is command frames which have a 16-bit command code and an argument. Looking at the tcp/ip link protocol and the web socket protocols the commands used in both is translated here to a binary form.

The second is reply frames which are designed for command replies to a client. Error codes and state information can be sent here.

Frame format and packet types is a bit confusing.

Packet type 0: Can have frame types 0/1. The frame type is defined in bit 8/9 of the VSCP event head. All frames will be promoted to frame type 1 with nan second timestamp.

Packet type 14: This is the command packet. Just one frame type.

Packet type 15: This is the reply packet. Just one frame type.

The helper library, vscphelper.cpp and vscp-firmware-helper.c will all support the binary protocol. So in reality it is not more work to use than to decide on encryption, share a secret key between devices and send/receive events (and commands) as before.

You can read more about the binary frames in the documentation. Some things may still change.

ps I try not to break things if possible but have done so in the vscp header (vscp.h) by removing the multicast defines and renames them to “binary”… Some applications may thus need to be recompiled after fixing the naming. Sorry for that, but this as a good time for doing this. ds

Michal Protasowicki made a very nice toolbox that simplifies work with VSCP over CAN. You find more information about it and download it here https://github.com/michpro/VSCP4CANToolBox