You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thank you to whomever in particular (e.g., Colin on discord) went to the trouble of extracting these references from the developer Android app sources. While I expect these specs being made available to help me get my Android application to accept Chameleon Mini I/O over Bluetooth, this device design without this spec (which was not released for the longest time) is nonstandard and hence nonsensical as most BLE devices would have a bidirectional single UUID service/characteristic to exchange the serial data, correct?
A couple of other points and questions to be issued:
This code (and here) hints at some undocumented ways of extracting more version and battery information from the device. Why is this not wrapped into new Chameleon terminal commands in the standard open source firmware sources (see also complaint below)?
What does this code enable? It makes me nervous by the monicker you give this functionality from here.
I do not appreciate the still very closed-source nature of the BT firmware (available only here at current). Why should I, or anyone else, trust the embedded BT BLE device's DFU capability to install a firmware binary I do not know the sources for? Still not a reasonable policy to me.
The text was updated successfully, but these errors were encountered:
In particular, a good reason to open source your BT firmware is to clarify what exactly the full set of commands (also here for another example) do on this device.
Thank you to whomever in particular (e.g., Colin on discord) went to the trouble of extracting these references from the developer Android app sources. While I expect these specs being made available to help me get my Android application to accept Chameleon Mini I/O over Bluetooth, this device design without this spec (which was not released for the longest time) is nonstandard and hence nonsensical as most BLE devices would have a bidirectional single UUID service/characteristic to exchange the serial data, correct?
A couple of other points and questions to be issued:
The text was updated successfully, but these errors were encountered: