I have done some tests to see the reaction time of the IMP and the wakeup time (measured).
- 50-80uS is actually not bad here. We’ll always be working to improve this time, but low latency IO should be dealt with by the imp OS (eg: serial buffering, pulse counting, etc). We’ve got some more stuff in the pipe which may help here… but what are you looking for?2. The data will reach the server, but you may not see it in the web client if you’re using server.show() as the web client looks for changes and reloads - but can easily miss updates. It’s not intended to be tightly coupled to the devices. If you’re wanting to log data, use server.log().3. Wakeup is currently very slow, as it reloads the squirrel from the server. When all the squirrel-in-flash things are done, this should be down to sub 100ms, possibly much, much faster.
1. I wanted to know for bitbanging "protocol" what is the limit for reaction time after edge change. Below 100uS should be enough so it's fine.
2. Good news - I will use log than.
3. Than for now I will avoid deep sleep and go with the normal edge callback, we'll see the deep sleep when the flash things are done.
Ty for the feedback.
We’re working on a bitbang list, where you specify the transaction in advance then “run” the bitbang, which will give much better resolution.
Bitbanging list is even better, already tried such thing for other rf chips and worked well. Waiting for it …