Category: VSCP

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

Version 15.1.0 of vscpl2drv-logger has been released.

• Release information and binaries is here
• Documentation is here.

Version 15.2.0 of vscpl2drv-websocksrv has been released.

• Release information is here
• Documentation is here.

VSCP Update

The documentation for VSCP products previously sold by Grodans Paradis AB has been offline for some time, as the original publishing system was discontinued and incompatible with later PHP versions. While these products have not been actively sold, the documentation also serves as reference code for VSCP devices communicating via CAN (CAN4VSCP). Over the past two weeks, I have updated the material to align with the system used for all other VSCP code, making it fully accessible and functional once again. Hopefully, this system will remain viable for many years.

During the recent component shortage, hardware sales were halted due to processor unavailability. However, my passion lies in designing these modules and transforming them into products — a pursuit I have dearly missed. As a result, Grodans Paradis AB will likely resume module sales, which also serve as reference hardware for VSCP.

Profit is not the goal here. Grodans Paradis AB uniquely encourages others to freely copy, modify, or adapt products, including selling them under one’s own name without referencing the original source or VSCP. Contributions and improvements are welcome but not required. The principle is simple: free and open access, as long as you build them yourself.

Currently, I am developing LoRa reference code and a few modules, with promising initial results. Work also continues on VSCP Works+ and demo firmware across multiple platforms using the new firmware stack. While larger than its predecessor, the new architecture allows for reusable, modular components that integrate seamlessly. Higher-level C++ classes now handle VSCP event transmission uniformly, independent of transport — functionality already implemented in VSCP Works+.

There is much I hope to accomplish, though energy and time are finite. Yet the past year has been remarkable. I deeply enjoy this work — the code, the hardware, the ideas. What began as a concept in the early 1980s has become something tangible and functional — my “child.” Like any creation, it is loved unconditionally, even if its full nature is elusive. Perhaps it is a form of sand art, transient yet meaningful. I have derived immense joy from this process, and that alone makes it worthwhile. One day, the windows must be thrown open, the wind allowed to sweep through, and one must move forward contentedly.

• Product documentation
• VSCP Works+
• VSCP firmware

/Ake