Streaming Pixl.js LCD Content over Web Bluetooth

Posted on
  • A new experiment I have been working on, allowing to easily add remote control (over Web Bluetooth) to existing Pixl.js projects:­display-over-web-bluetooth-bb9ff2cb5d30

    In action:

    Espruino-mirror In Action

  • 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?­888/

  • @urish, you picked yourself a nice, challenging cherry... or may be more like a basked full of all kinds of tasty cherries...

    (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...

    To stay responsive - to remote control commands - I'd separate the sync out from the flip with a snapshot buffer and frequency limiting timer, and also make the loop over the chunks javascript process interruptible. For the actual transmission, I would implement a (multi queue, queue, multi-priority) queued channel / time multiplex system so that each packet can transmit what ever is of highest priority. Load of the queue would slow down the frequency of the display sync events (delay the completion of the current one, up to the point with deferring the start of the next one)... For the screen streaming, it become then like a flip-flip or double-flip / multi-flip pattern when looking from start to finish of one complete screen update.

    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...

    • Espruino keeps track of the area of the display that's modified with g.getModified() - so potentially you could send just the area of the screen that changed to make it faster?
    • Espruino v2 has the 'heatshrink' library for LZSS compression which you could use to get the size down. I don't think there's a JS implementation (looks like there may be a TypeScript decompressor), but I guess one could be built with emscripten.

    I'm totally up for increasing the MTU size in Espruino as well - just have to figure out how to do it :)

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview

Streaming Pixl.js LCD Content over Web Bluetooth

Posted by Avatar for urish @urish