Most recent activity
-
I'd like to suggest a couple feature requests for setWatch. I looked at making the code changes myself and while I think I could manage the JavaScript interface changes the event queuing and low level coding is beyond my pay grade, or at least my C++ competency. :)
It would be nice if the repeat parameter accepted an integer value rather than just a Boolean. That would allow one to look for a specific number of transitions and limit overwhelming the event queue for continuous frequency signals.
It would be nice to add a prescale parameter such that some number of transitions must occur for each generated event. My thought here is that this needs to be incorporated at the interrupt level. This would enable observing rapidly changing continuous signals again without overwhelming the event queue.
-
Thanks. I don't think you are the "bringer of bad news." It's nice to get some honest answers. I am recently retired and Ok with just contributing but a friend is considering possibly building a business around small project boards.
I do think unfortunately for you your Espruino works carries an unusually high "large Open Source software element" compared to many shield/hat type projects that could potentially sell a reasonable number of boards with much less software overhead and maintenance.
But, kudos to you for your vision of Espruino and delivering on it. For decades I have thought that it would be awesome to have a microprocessor that could run interpretive scripts on the fly rather than fixed compiled C code or overly complicated and insecure OS based hardware. I hope it remains profitable for you to continue. Thanks again.
-
Any info on Espruino board sales, development hours, supplier dealings, build costs, flow, open source hardware, and your personal experience with such that you would be willing to share for helping others interested in getting started with similar projects?
-
What about a sequence number ? This should allow the receiver to identify if a message is missing.
Yes, useful for flagging lost data but i wouldn't recommend for validating data, that is, you don't want to rely on having to receive every sequential packet. It's probably not as easy to recover a missing packet as it is to just design with expectation of missing samples. Recovery means having to queue each data packet until you get an acknowledgement for each, which means memory resources and additional overhead for handshaking too, pretty significant for small devices like Espruino.
It can be useful for rolling a secret code too, essentially what garage door openers do.
-
First I've seen this thread, but I can suggest an alternative less resource intensive solution that I have used...
Assumptions... @Gordon initial premises of low resources, low message overhead, validating message integrity, use of a predefined secret, and use of the built-in SHA256 hash function; however, no message encryption. This can be extended to Puck.js security as well.
Consider that sometimes authentication of the message can be more important than the actual message -- the message bears the kings seal! For example, if I want to read a sensor value or send a message to open/close a garage door, particularly within a small coverage area such as BLE vs the global Internet, I may not need to encrypt the message if I can validate that the message is authentic. In other words who cares what the message says if I can discriminate and trust who sent the message.
This involves a much simpler and faster procedure. For a string of "data", you calculate an authentication hash equivalent say to the following pseudo-code.
hash = SHA256(salt+epoch+secret+data); message = {data:data, salt:salt, epoch:epoch,hash:hash, version:1};Where salt is a random prefix string, typically 2-8 characters, to ensure sending the same message does not generate the same hash response; epoch is a time stamp that enables checking that the message was generated within a valid time window (i.e. sent just now, not a replay from yesterday. Also, need to be able to sync time.); secret is a piece of information known only by the sender and receiver and never passed openly (although this may be required one time in a learn mode, which presumably you can control); and the optional version provides identification of the scheme used that allows the receiver to discriminate different formats and enables a migration path to newer schemes.
Note the salt, epoch, and the hash get passed with the data message. The receiver uses the same code to generate the same hash locally, using the locally known secret. If the sent message hash matches the locally generated hash, the message is authentic so act on it; otherwise, ignore the message or report it as a bad request perhaps. The hash also acts as a "checksum" to validate the integrity of the data. A single bit error will radically alter the generated hash.
If the overhead of the hash, salt, and epoch represent to much bandwidth burden, many options exist. For example, send a simple string instead of a JS object with the fixed length version (1 byte), salt (2 byte), epoch (4 byte), and hash (32 bytes) prefixed to the data string, which the receiver can very easily parse by fixed substrings. Alternately, the hash can be truncated as a trade with security. A 4 byte hash for example still has 256^4 or ~1:4 billion chance of being replicated, probably good enough for most personal sensor/actuator applications. Assuming 5 byte hash, you only add 12 bytes overhead per message, which even works for the limited BLE message size.
Another feature I like is that with an initial stored secret, the secret used for the hash can itself be adapted on the fly or on (authenticated) command. For example, you could hash the stored secret with a client provided random string, which changes the key for the specific message at the request of the client. Or roll the key based on a variable such as the day of the week. Or generate the key internally to the transmitter perhaps with a PUF -- see https://en.wikipedia.org/wiki/Physical_unclonable_function
There are many variations on this theme, but...
- Always randomize the message (i.e. salt it).
- Never pass the secret (other than possibly a controlled one time learn).
- Pass time and build in a time syncing capability.
- Always randomize the message (i.e. salt it).
-
Perhaps you could add a timeout to autolock the console after a period of inactivity.
-
For those wanting to understand more NRF52832 details, Nuts and Volts magazine has run a series of articles on various hardware aspects in the 11/2016 to 1/2017 issues.
http://www.nutsvolts.com/magazine/article/November2016_DesignCycle_Nordic-nRF52832-BLE
http://www.nutsvolts.com/magazine/article/December2016_DesignCycle
http://www.nutsvolts.com/magazine/article/January2017_DesignCycle
I like those ideas too. setWatch offers a nice clean way to monitor I/O and generate events and embellishing it would open the door to more sophisticated events.
Then perhaps a
countparameter?