#6lowpan — Public Fediverse posts

EDHOC, the lightweight key exchange for #IoT devices, is now published as #RFC 9528. It enables state of the art elliptic curve based security after exchanging 3 messages of only a bit over 100 bytes in total, thus fitting in even the lowest power networks such as #6LoWPAN and #LoRA.
Thanks and congratulations to Göran, John and Francesca for making security more affordable.
https://www.rfc-editor.org/rfc/rfc9528.html

EDHOC, the lightweight key exchange for #IoT devices, is now published as #RFC 9528. It enables state of the art elliptic curve based security after exchanging 3 messages of only a bit over 100 bytes in total, thus fitting in even the lowest power networks such as #6LoWPAN and #LoRA.
Thanks and congratulations to Göran, John and Francesca for making security more affordable.
https://www.rfc-editor.org/rfc/rfc9528.html

EDHOC, the lightweight key exchange for #IoT devices, is now published as #RFC 9528. It enables state of the art elliptic curve based security after exchanging 3 messages of only a bit over 100 bytes in total, thus fitting in even the lowest power networks such as #6LoWPAN and #LoRA.
Thanks and congratulations to Göran, John and Francesca for making security more affordable.
https://www.rfc-editor.org/rfc/rfc9528.html

EDHOC, the lightweight key exchange for #IoT devices, is now published as #RFC 9528. It enables state of the art elliptic curve based security after exchanging 3 messages of only a bit over 100 bytes in total, thus fitting in even the lowest power networks such as #6LoWPAN and #LoRA.
Thanks and congratulations to Göran, John and Francesca for making security more affordable.
https://www.rfc-editor.org/rfc/rfc9528.html

EDHOC, the lightweight key exchange for #IoT devices, is now published as #RFC 9528. It enables state of the art elliptic curve based security after exchanging 3 messages of only a bit over 100 bytes in total, thus fitting in even the lowest power networks such as #6LoWPAN and #LoRA.
Thanks and congratulations to Göran, John and Francesca for making security more affordable.
https://www.rfc-editor.org/rfc/rfc9528.html

Can Contiki NG and Linux communicate via 6LoWPAN / IEEE 802.15.4?

English: https://mk16.de/blog/contiki-ng-linux-wpan-6lowpan-en/
German: https://mk16.de/blog/contiki-ng-linux-wpan-6lowpan-de/

#WPAN #6LoWPAN #Contiki #ContikiOS #ContikiNG #IEEE802154

Can Contiki NG and Linux communicate via 6LoWPAN / IEEE 802.15.4?

English: https://mk16.de/blog/contiki-ng-linux-wpan-6lowpan-en/
German: https://mk16.de/blog/contiki-ng-linux-wpan-6lowpan-de/

#WPAN #6LoWPAN #Contiki #ContikiOS #ContikiNG #IEEE802154

Can Contiki NG and Linux communicate via 6LoWPAN / IEEE 802.15.4?

English: https://mk16.de/blog/contiki-ng-linux-wpan-6lowpan-en/
German: https://mk16.de/blog/contiki-ng-linux-wpan-6lowpan-de/

#WPAN #6LoWPAN #Contiki #ContikiOS #ContikiNG #IEEE802154

Can Contiki NG and Linux communicate via 6LoWPAN / IEEE 802.15.4?

English: https://mk16.de/blog/contiki-ng-linux-wpan-6lowpan-en/
German: https://mk16.de/blog/contiki-ng-linux-wpan-6lowpan-de/

#WPAN #6LoWPAN #Contiki #ContikiOS #ContikiNG #IEEE802154

After a year of work, mainly by @jia200x, we now have support for #OpenDSME in our development branch. This implementation of the DSME mode of 802.15.4 allows #6LoWPAN devices to stay available in low power sleep modes without the elaborate central control of timing and channels.

After a year of work, mainly by @jia200x, we now have support for #OpenDSME in our development branch. This implementation of the DSME mode of 802.15.4 allows #6LoWPAN devices to stay available in low power sleep modes without the elaborate central control of timing and channels.

After a year of work, mainly by @jia200x, we now have support for #OpenDSME in our development branch. This implementation of the DSME mode of 802.15.4 allows #6LoWPAN devices to stay available in low power sleep modes without the elaborate central control of timing and channels.

After a year of work, mainly by @jia200x, we now have support for #OpenDSME in our development branch. This implementation of the DSME mode of 802.15.4 allows #6LoWPAN devices to stay available in low power sleep modes without the elaborate central control of timing and channels.

After a year of work, mainly by @jia200x, we now have support for #OpenDSME in our development branch. This implementation of the DSME mode of 802.15.4 allows #6LoWPAN devices to stay available in low power sleep modes without the elaborate central control of timing and channels.

@train Give it a try, it's not that hard once you let go of v4 preconceptions – and enables nice applications like #6LoWPAN ("real" #IoT 😃) that can do only v6 and is really awkward to use without a v6 uplink.

@train Give it a try, it's not that hard once you let go of v4 preconceptions – and enables nice applications like #6LoWPAN ("real" #IoT 😃) that can do only v6 and is really awkward to use without a v6 uplink.

@train Give it a try, it's not that hard once you let go of v4 preconceptions – and enables nice applications like #6LoWPAN ("real" #IoT 😃) that can do only v6 and is really awkward to use without a v6 uplink.

@train Give it a try, it's not that hard once you let go of v4 preconceptions – and enables nice applications like #6LoWPAN ("real" #IoT 😃) that can do only v6 and is really awkward to use without a v6 uplink.

@train Give it a try, it's not that hard once you let go of v4 preconceptions – and enables nice applications like #6LoWPAN ("real" #IoT 😃) that can do only v6 and is really awkward to use without a v6 uplink.

I've just thrown this little page together…

http://vk4msl.com/2023-backburn/

I'll probably get rid of it once the backburning is passed, but this is the raw data along with the current conditions. The current conditions update each minute (self-refreshing).

I might see if I can get a chart going on it, the data's there.

Data flow is from the data logger → #6LoWPAN mesh → #CoAP proxy → #WideSky back-end → #pyhaystack → JSON files to be served up by #OpenHTTPD

The pyhaystack script runs from `cron`.

I've just thrown this little page together…

http://vk4msl.com/2023-backburn/

I'll probably get rid of it once the backburning is passed, but this is the raw data along with the current conditions. The current conditions update each minute (self-refreshing).

I might see if I can get a chart going on it, the data's there.

Data flow is from the data logger → #6LoWPAN mesh → #CoAP proxy → #WideSky back-end → #pyhaystack → JSON files to be served up by #OpenHTTPD

The pyhaystack script runs from `cron`.

I've just thrown this little page together…

http://vk4msl.com/2023-backburn/

I'll probably get rid of it once the backburning is passed, but this is the raw data along with the current conditions. The current conditions update each minute (self-refreshing).

I might see if I can get a chart going on it, the data's there.

Data flow is from the data logger → #6LoWPAN mesh → #CoAP proxy → #WideSky back-end → #pyhaystack → JSON files to be served up by #OpenHTTPD

The pyhaystack script runs from `cron`.

I've just thrown this little page together…

http://vk4msl.com/2023-backburn/

I'll probably get rid of it once the backburning is passed, but this is the raw data along with the current conditions. The current conditions update each minute (self-refreshing).

I might see if I can get a chart going on it, the data's there.

Data flow is from the data logger → #6LoWPAN mesh → #CoAP proxy → #WideSky back-end → #pyhaystack → JSON files to be served up by #OpenHTTPD

The pyhaystack script runs from `cron`.

I've just thrown this little page together…

http://vk4msl.com/2023-backburn/

I'll probably get rid of it once the backburning is passed, but this is the raw data along with the current conditions. The current conditions update each minute (self-refreshing).

I might see if I can get a chart going on it, the data's there.

Data flow is from the data logger → #6LoWPAN mesh → #CoAP proxy → #WideSky back-end → #pyhaystack → JSON files to be served up by #OpenHTTPD

The pyhaystack script runs from `cron`.

Okay… got the thing awake. I've flashed it with full-thread device firmware so it won't go to sleep… it's running on a bench supply so it won't run out of power.

I'll tweak some settings on here, see if I can get minute-by-minute samples of the air quality.

The CC2538-based device is pushing data via a #6LoWPAN network to a #CoAP server which proxies the request to a HTTP back-end. #Grafana is plotting the output.

Okay… got the thing awake. I've flashed it with full-thread device firmware so it won't go to sleep… it's running on a bench supply so it won't run out of power.

I'll tweak some settings on here, see if I can get minute-by-minute samples of the air quality.

The CC2538-based device is pushing data via a #6LoWPAN network to a #CoAP server which proxies the request to a HTTP back-end. #Grafana is plotting the output.

Okay… got the thing awake. I've flashed it with full-thread device firmware so it won't go to sleep… it's running on a bench supply so it won't run out of power.

I'll tweak some settings on here, see if I can get minute-by-minute samples of the air quality.

The CC2538-based device is pushing data via a #6LoWPAN network to a #CoAP server which proxies the request to a HTTP back-end. #Grafana is plotting the output.

TIL about BeagleConnect™, which makes it possible for #mikroBUS based Click boards to be connected wirelessly (e.g. via #6LoWPAN over
802.15.4) to a #linux gateway.

A virtual bus is created on the Linux gateway (e.g. /dev/i2c3) that sends "bridged PHY" #greybus messages to the remote #IoT node. The remote node runs #zephyr firmware on an MCU that speaks the Greybus protocols and translates those messages into I2C, SPI, GPIO, etc on the Click sensor (no drivers on MCU!)

https://git.beagleboard.org/beagleconnect/freedom

TIL about BeagleConnect™, which makes it possible for #mikroBUS based Click boards to be connected wirelessly (e.g. via #6LoWPAN over
802.15.4) to a #linux gateway.

A virtual bus is created on the Linux gateway (e.g. /dev/i2c3) that sends "bridged PHY" #greybus messages to the remote #IoT node. The remote node runs #zephyr firmware on an MCU that speaks the Greybus protocols and translates those messages into I2C, SPI, GPIO, etc on the Click sensor (no drivers on MCU!)

https://git.beagleboard.org/beagleconnect/freedom

TIL about BeagleConnect™, which makes it possible for #mikroBUS based Click boards to be connected wirelessly (e.g. via #6LoWPAN over
802.15.4) to a #linux gateway.

A virtual bus is created on the Linux gateway (e.g. /dev/i2c3) that sends "bridged PHY" #greybus messages to the remote #IoT node. The remote node runs #zephyr firmware on an MCU that speaks the Greybus protocols and translates those messages into I2C, SPI, GPIO, etc on the Click sensor (no drivers on MCU!)

https://git.beagleboard.org/beagleconnect/freedom

TIL about BeagleConnect™, which makes it possible for #mikroBUS based Click boards to be connected wirelessly (e.g. via #6LoWPAN over
802.15.4) to a #linux gateway.

A virtual bus is created on the Linux gateway (e.g. /dev/i2c3) that sends "bridged PHY" #greybus messages to the remote #IoT node. The remote node runs #zephyr firmware on an MCU that speaks the Greybus protocols and translates those messages into I2C, SPI, GPIO, etc on the Click sensor (no drivers on MCU!)

https://git.beagleboard.org/beagleconnect/freedom

TIL about BeagleConnect™, which makes it possible for #mikroBUS based Click boards to be connected wirelessly (e.g. via #6LoWPAN over
802.15.4) to a #linux gateway.

A virtual bus is created on the Linux gateway (e.g. /dev/i2c3) that sends "bridged PHY" #greybus messages to the remote #IoT node. The remote node runs #zephyr firmware on an MCU that speaks the Greybus protocols and translates those messages into I2C, SPI, GPIO, etc on the Click sensor (no drivers on MCU!)

https://git.beagleboard.org/beagleconnect/freedom