A new experiment I have been working on, allowing to easily add remote control (over Web Bluetooth) to existing Pixl.js projects:
That's cool, I like it!
In other message I ask about reading a 57x57 pixels QRCode from the pixl's screen, the idea is that you read it with the phone and it takes you to a web page where you can configure it, so the UI of the device setup/config is just a matter of a bit of html+js that runs on the browser on the phone, and I'm relieved of having to program it all from scratch to run on the espruino.
Hey, could you please transfer these QRCode images to the Pixl and try to read them with your phone, please?
@urish, you picked yourself a nice, challenging cherry... or may be more like a basket full of all kinds of tasty fruits...
(forum entry got somehow duplicated while editing it... so I break it apart at this spot).
NOT btw, I notice the subtile - subversive? - presence of lovely 'fine' art in the prevailing cold, stone hard technology information stream... (there are obviously still cycles available to burn on non-essentials... which make life worth living!)
There are some nice challenges in the implementation, I feel... and can think of right of the bat...
The synchronous and uninterrupted transmission of the screen triggered by the .flip() is a great start. I do though not know about the side effects that keeps you BLOCKED / un-interruptable busy for 40% of the time assuming a .flip() happens (at least?) about every second... It does with the (implied) clock application, when seconds are in use...
A simple setup with only a few things but very interesting and sufficient to study the many issues communication w/ band limitation faces... and visualize what actually is going on.
Side note: Version 2v00 celebration w/ my 2k-th post... ;-)
Wow - that's great!
Just a few random thoughts...
I'm totally up for increasing the MTU size in Espruino as well - just have to figure out how to do it :)
So I made a few tweaks following lots of @Gordon's advice, and I got it to support 50ms frame delay.
Wow, that's very cool. Do you have the code you used?
Did you use heatshrink in the end, or was it just only sending the contents that had changed?
Lovely! I'd love to see the updated code as well - or if you are up to it, a Pull Request will also be appreciated :)
@Gordon its just using heatshrink. More savings to be made if we sent just the changes as well but we'd need two packet types then, one for the initial "full" send, and then another for just updates.
@urish I will work on a pull request, the code is very bad at the moment. I need to send 1 frame of all 0x00 bytes before the real frames, then 1 frame of 0xFF bytes so that we can identify the "real" frames and make sure they are in order (sometimes they out OOO even though BLE should order them). I'm sure there are many improvements to be made.
Awesome. What did you use for the heatshrink decoding in the end? It'd be great to get a link to that in the docs as it seems like a pretty common use case
I went with https://www.npmjs.com/package/heatshrink-ts just had to configure it with the
WINDOW_BITS, LOOKAHEAD_BITS, INPUT_BUFFER_LENGTH
parameters that you found for me.
Don't worry about formatting, just type in the text and we'll take care of making sense of it. We will auto-convert links, and if you put asterisks around words we will make them bold.
For a full reference visit the Markdown syntax.
© Espruino, powered by microcosm.
Report a problem