I’m doing Open Source primarily because I love it. The social aspects, the for-the-good angle and for the challenge of engineering this to work for everyone. I also do it because it is my full-time job and getting food on the table and provide for my family is not unimportant. It may come as a … Continue reading The pressure →
Source: The pressure | daniel.haxx.se
Check out there site https://wiznet.io
With Flipper One, we’re reimagining what a Linux cyberdeck can be — it’s a huge project. We’re opening up the development process and asking the community for help.
Source: Flipper One — we need your help
When I come home today the new cards are delivered from JLCPCB in China.
Have to do some other stuff first before I can look closer. Typically…
Looks good. Four layer boards this time.
And it fits in the new enclosure to. Happy. Build and test tomorrow (hopefully). The code for this WIFI to CAN4VSCP hardware is already done and working.
Just to be clear. JLCPCB does not sponsor my boards. I can recommend them anyway. Six days from order to delivery using Europack. Superb quality.
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.
MeshCore or Meshtastic
Source: MeshCore or Meshtastic: Which one is better? – Latest News from Seeed Studio
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