Just using the blink codes in a browser window?
Technically possible if you can maintain an exact 60fps… I’ve not seen that work in a browser, though.
It’s not the fps of the update, it’s that it has to be perfectly tied to the FPS of the display device. Anything that is saying it’s doing 120fps is an instant fail here, as it shouldn’t be able to go above the output device refresh rate.
As I understand it window.requestAnimFrame is meant to be frame synced. However I just tried it and got (an extremely consistent) 62.5 fps. So go figure.
Maybe a imp with a LED can be used to program other imps?
Maybe a change to how blinkup works. Count only the transitions, a=1 blink, b=2 blink, etc. each letter followed by silence. That would take longer to blink out but reduce your dependence on timing. Also, I think manchester encoding helps with timing slips. Just some thoughts …
Manchester coding doesn’t help with timing slips in our case I’m afraid, but we have another method which appears to work well in our testing and if all goes well will be released next week. Takes twice as long, but much better than the current frustration if your phone can’t keep up!
I did think of a certain solution - progmatically create a “blinkup movie” with 60fps frame rate, then play it back using any decent movie player. It might even work on mobile devices. However I think all of this is going to become completely irrelevant when the Android app is fixed next week and Apple eventually deign to allow us to have the iOS version.
it’s also a good question if blinking only one part of the screen (1cmx1cm) wouldn’t be much better for slower android phones. Now the whole screen is blinked which obviously is slower … Today I got a Motorola but that doesn’t works either - seems that <250$ Android phones are simply not strong enough for the current 60fps api which is kinda frustrating. And ofc apple still not moving with that api … grrrr