Most recent activity
-
- 4 comments
- 2,263 views
-
Nope, not HID.
The desktop application side is listening for events that are incoming from a ROS topic over a websockets connection (with roslibpy).
The bridge between puck.js and ROS is a very trivial webpage (source) that connects to the puck.js, and starts an interval to send over the knob's value (an analog pin read) (and also the capsense value, that I didn't use so far). That same page publishes the value to ROS topics via websockets as well.
All and all, it's extremely simple, but it uses a bunch of very unrelated technologies. ;)
-
-
-
It's actually what I had in my drawer of enclosures, and I think it's actually aluminum, but for my silly use case, it works well enough, it's not blocking the RF connection. But it's a hack, a proper product design would change to a square form factor to be more composable with multiple knobs, and I would replace the top side of the box with glass-like black material.
-
before I go off trying to do my own thing
yep, I'd advice against building it yourself unless you have a lot of extra time in your hands. Not sure what's your project exactly, but unless your goal is really to build a packet forwarder in node.js, then go with lora-server (or TTN, or a loriot.io community account) as your backend.
Unless -of course- you're trying to build an espruino-powered lorawan gateway :)
-
Hey @Gordon, in general, TTN shouldn't differ much (at all?) from any other LoRaWAN network. I haven't tested myself, but there are a bunch of guys in our local community that have sensors that they interchangeably switch from network to network without issues.
If you wanna setup a local test environment to isolate from TTN and any other provider, I'd recommend this backend: https://github.com/brocaar/loraserver It's well documented and I know others have tried it successfully. About the concentrator, I guess you have it figured it by now, but you could use TTN install scripts (https://github.com/ttn-zh/ic880a-gateway/wiki) and just change the backend server to forward to on the local_conf.json
The biggest problems you will face with downlink (from backend to espruino) are related to time sync, the receive window is rather small, and it's a source of constant issues on some MCUs.
Let me know if I can give you a hand.
Cheers
GonzaloEDIT: Actually, I DID test switching networks now that I remember, and it worked without having to make changes to my node. Just provision the keys on the new network and off you go.
I'm kind of new around, wanna go for a coffee?