18th-Nov-23, 10:19 AM
Hi Drifter2, I think you are right.
That said, it was an extremely interesting challenge looking in depth at ICP to address the braided issue run-aways which I did in collaboration with my kind friend Dave. Over the months we looked into a whole range of potential causes. In the end, we pinned the problem down to electrical noise generated by braid-to-braid friction though there were some other contributing factors along the way too. We were then able to refine the firmware code appropriately and the issue was finally sorted. Literally a ‘game changer’.
Interestingly we saw similar issues with other brands of decoders that used track packets for communications. At times we used nRF wireless modules to telemeter the status of the decoder prior to, during and after runaways had occurred. This included telemetry of the number of ‘good’ data packet reads per second - typically 50 per second for SSD.
The conclusion of this work is that we believe we now know how to make rock solid run-away-free decoders which use track packet protocols.
So coming back to Drifter2’s point - yes probably the end of the road for ICP development but the learning along the way for sure will inform our future decoder designs - both hardware and firmware.
As mentioned elsewhere our focus is now on C++ decoder firmware rather than asm as used for ICP. Faaaaaasrrrrrrrrrrr easier!
Yes, time for new code, new features and new branding.
c
That said, it was an extremely interesting challenge looking in depth at ICP to address the braided issue run-aways which I did in collaboration with my kind friend Dave. Over the months we looked into a whole range of potential causes. In the end, we pinned the problem down to electrical noise generated by braid-to-braid friction though there were some other contributing factors along the way too. We were then able to refine the firmware code appropriately and the issue was finally sorted. Literally a ‘game changer’.
Interestingly we saw similar issues with other brands of decoders that used track packets for communications. At times we used nRF wireless modules to telemeter the status of the decoder prior to, during and after runaways had occurred. This included telemetry of the number of ‘good’ data packet reads per second - typically 50 per second for SSD.
The conclusion of this work is that we believe we now know how to make rock solid run-away-free decoders which use track packet protocols.
So coming back to Drifter2’s point - yes probably the end of the road for ICP development but the learning along the way for sure will inform our future decoder designs - both hardware and firmware.
As mentioned elsewhere our focus is now on C++ decoder firmware rather than asm as used for ICP. Faaaaaasrrrrrrrrrrr easier!
Yes, time for new code, new features and new branding.
c
![[+]](https://slotracer.online/community/images/bootbb/collapse_collapsed.png)