Quite likely related to the problem described above.
Occasionally, it appears that the iCP will drop a nub value from the 4 values passed
Are you using the very latest firmware? There were some nub issues in the software that were discovered in joystick mode and it would apply here too. It was a problem related to full extent values of the nub so this is probably it.
Moving a nub fully to the left seems to stop the other nub from reporting any values until you pull back a bit on the other nub.
I'm currently running firmware 1.0.1a
I looked more into this issue (when pressing the nub fully to the right (not left like I said above) stopping events) and I believe I see what's going wrong. If you move either nub fully (or mostly fully) to the right
, the iCP starts to only send 4 bytes instead of the normal 5 - and in the code I wrote, I assume the packet is corrupt and ignore that packet - hence no movement of any nubs on the iPhone. Here's an example (note: all tested on OSX - but also verified on iOS sim and device):Left nub fully left
w2A@@w(B@@w$A@@w$B@@w$D@@w$B@@w$A@@w$D@@w$A@@w A@@w D@@w B@@w A@@w)A@@w@@@@Left nub fully right
wB@@wA@@wB@@wA@@w^A@@wA@@wD@@w@@@@Right nub fully right
As you can see, the first capture is correct (as it is with all other nub directions) with a 5 byte packet, but 2 and 3 show the missing byte when either nub is fully to the right. I'm guessing this might be some sort of firmware issue - maybe overflow when at max value? This is really the only main bug I'm still seeing. I could work around it by handling a 4 byte packet - though it'd be handy to know what the dropped byte means
Maybe just assume it's at max value and track which nub it most likely belongs to? BTW, anyone reading along and seeing those 'gaps' in the first capture should realize that the space character (32) is a valid value and represents -32
If you can keep the controls in one position then no new data gets sent. It only sends data on changes. There used to be a control register to chose between this method and constant update but constant update basically killed the communication from iCP to host (tested on my PCs and iPods). The data rate was way, way beyond what a keyboard driver expected to receive and it crapped all over itself.
- I still can't quite tell if the iCP keeps streaming nub coords even when you're trying to hold the nub in place (I don't think so, but it does seem very sensitive to slight movements - hence the suggestion for reducing the granularity of the coords when in this mode)
Great! - this was what I expected (only updating on position/button changes) - definitely the best way.
There is a register that can be programmed in SPP mode that will create dead zones in the nub. You can set it to anything from 0 - 31. This can be used to prevent small, useless movements from sending a bunch of data over the link. I don't think a dead zone of 31 would be wise though.
The SPP mode does look cool, but I don't think I can ask a regular iOS user to reprogram their iCP by connecting it to the PC/Mac and adjusting their deadzones
Maybe defaulting to something more on the safe side is best.
That's definitely one way to do it. Right now everything is full range for people to experiment with but if no one needs that level of granularity, it could be stripped out.
- Maybe use 2 bits within the coord char passed to specify which nub and axis the value refers too, so if the player is only moving one nub on one axis, the iCP is only sending 2 chars ('w' and value) - combined with the stream suggestions above, it might only be sending 1 char on value changes)
I had a simple idea for something like this to go from 5 bytes down to 3: One byte per nub: <X sign><Y sign><XXX><YYY>
It gives you 7 levels in each direction with zero at any polarity meaning no deflection. With these little nubs, that might be all anyone needs and I might look into it for firmware 1.0.2.
Personally, I think this would be a nice way to handle it - from 5 bytes to 3. The only concern I have is whether iOS 4.* can handle an input char in the range of 0-255 instead of the normal printable ascii range of 32-127. There's a chance that any char outside of this range might get dumped before being passed to the app. Have you tried it? If you want, you can send me a firmware with this enabled and I can see what happens - and which, if any, bytes don't make it through. The other issue would is not being able to use 'w' as a reliable tag in the stream as it could be a possible nub value - though as long as it remains in 3 byte chunks, it shouldn't really be an issue - and I can still write code that can recover from the odd dropped char if needed.
It does appear to need to be slowed down a bit to maintain data integrity from iCP to host. Going from 13 to 10 should do it. 13 works on my unit but obviously I see now that not all devices can handle it as it is right at the edge of capability. I've been looking forward to getting feedback from others on this stuff.
- I'm not sure what the iCP firmware poll rate is for detecting/sending char events - but maybe reduce it? Maybe 10hz? 5?
I think 10hz would be great (I run my network physics at a 10hz input rate, so would fit in well with that
) - though honestly, I think 13 might be fine as well - assuming that bug above is related to a firmware issues instead of iOS clamping the keyboard input rate.
Thanks very much for looking into this mweston!!