Posts by Slot.it
1 - 10 of 10 Posts
Yes Cristian is taking a look. It is likely Greg.
For reasons outside our control, we'll be closed next week.
We have rearranged all work in order to stay open until today with minimum interaction between people. Cristian has been working from home but next week is forced holidays for everyone regardless as we decided that we all need a break.
For reasons outside our control, we'll be closed next week.
We have rearranged all work in order to stay open until today with minimum interaction between people. Cristian has been working from home but next week is forced holidays for everyone regardless as we decided that we all need a break.
Hi all. I'm working from home but still working albeit at a different pace. Let's put it this way: the virus made me understand how much I needed it.
Back to the troble at hand: Cristian is checking the code for bugs, but in principle, pressing the LC button equals to 'both buttons pressed' whereas the brake does just that - brake button pressed.
There is a subtle thing to consider: as there is no 'both buttons pressed' single bit, the condition is valid when both 'up' and 'down' bits are active. In theory, on the ARC PRO, as there is one button only, the bits should become active in one single go. This is what we're checking, to make sure that, for example, we're not setting one before the other, which may create confusion on the receiver's end.
Back to the troble at hand: Cristian is checking the code for bugs, but in principle, pressing the LC button equals to 'both buttons pressed' whereas the brake does just that - brake button pressed.
There is a subtle thing to consider: as there is no 'both buttons pressed' single bit, the condition is valid when both 'up' and 'down' bits are active. In theory, on the ARC PRO, as there is one button only, the bits should become active in one single go. This is what we're checking, to make sure that, for example, we're not setting one before the other, which may create confusion on the receiver's end.
If I understand correctly, what I mean is this
The code base fot the SCP3 and ARC PRO is the same - except for some conditional compilations that cope with the hardware differences.
The ARC has two buttons only, only one of them dedicated to LC. SCP has two LC, one brake.
The oXigen protocol dedicates two bits for each of the lane change buttons - this information is sent from the controller to the dongle.
When you press two buttons at once, phisically you almost never press them at the same time. Because the data is samped very quickly, it is likely that you will have a transition from 'no button pressed' to 'one button pressedn' to 'both buttons pressed'.
In boolean logic terms this is called a 'race' condition - one bit is set before the other when you want BOTH bits to be set. Therefore, the state of the bits will be something like 00 -> 01 -> 11 quite often as it depends on your fingers.
Similarly, when you release the buttons, the system will likely go from 'both buttons pressed' to 'one button pressed' to 'no button pressed'.
If undetected this can trigger some undesired behaviour.
With an ARC controller, as there is only on LC button which triggers the same LC strategy as pressing both buttons at once in an SCP controller, when the button is pressed both bits are set to 1 at the same time
from 00 --> 11 without transition.
With the app, we will be able to, say, define that for ARC PRO the LC means up or down, and breake means enter, or whatever - bit sets may be mapped to the buttons.
Your suggestion for RCS02 may be equally valid, but yes, unless RCS differentiates between ARC PRO and SCP, any changes to the menu selection logic will apply to both.
The code base fot the SCP3 and ARC PRO is the same - except for some conditional compilations that cope with the hardware differences.
The ARC has two buttons only, only one of them dedicated to LC. SCP has two LC, one brake.
The oXigen protocol dedicates two bits for each of the lane change buttons - this information is sent from the controller to the dongle.
When you press two buttons at once, phisically you almost never press them at the same time. Because the data is samped very quickly, it is likely that you will have a transition from 'no button pressed' to 'one button pressedn' to 'both buttons pressed'.
In boolean logic terms this is called a 'race' condition - one bit is set before the other when you want BOTH bits to be set. Therefore, the state of the bits will be something like 00 -> 01 -> 11 quite often as it depends on your fingers.
Similarly, when you release the buttons, the system will likely go from 'both buttons pressed' to 'one button pressed' to 'no button pressed'.
If undetected this can trigger some undesired behaviour.
With an ARC controller, as there is only on LC button which triggers the same LC strategy as pressing both buttons at once in an SCP controller, when the button is pressed both bits are set to 1 at the same time
from 00 --> 11 without transition.
With the app, we will be able to, say, define that for ARC PRO the LC means up or down, and breake means enter, or whatever - bit sets may be mapped to the buttons.
Your suggestion for RCS02 may be equally valid, but yes, unless RCS differentiates between ARC PRO and SCP, any changes to the menu selection logic will apply to both.
Such a differentiation would not be reliable I'm afraid. The 'race' transitional condition between the bits is temporary and totally random, depending mostly by the user's dexterity, mechanics, and sampling interval. It cannot be counted on.
HOWEVER... it came to my mind that in our protocol, there's a header that says whether the controller is a SCP2, SCP3, or ARC PRO controller.
I'm not sure whether this information is relied to the PC from the dongle already
Therefore, RCS02 may differentiate between the two, and a different approach uses for ARC PRO.
So for SCP, Up is Up, Down is Down, Brake is Enter.
For example:
1 - LC - Scroll UP. Brake - Scroll down. If trigger is pressed fully within, say, 1" after either button is released, take it as 'enter'. Or
2 - LC - UP. Brake - Down. If you keep a button pressed and you press the other as well, that's 'Enter'
HOWEVER... it came to my mind that in our protocol, there's a header that says whether the controller is a SCP2, SCP3, or ARC PRO controller.
I'm not sure whether this information is relied to the PC from the dongle already
Therefore, RCS02 may differentiate between the two, and a different approach uses for ARC PRO.
So for SCP, Up is Up, Down is Down, Brake is Enter.
For example:
1 - LC - Scroll UP. Brake - Scroll down. If trigger is pressed fully within, say, 1" after either button is released, take it as 'enter'. Or
2 - LC - UP. Brake - Down. If you keep a button pressed and you press the other as well, that's 'Enter'
Hi all.
We have just released a new RCSO2 friendly version of
1 - firmware for Scalextric ARC PRO 3.10
2 - Bootloader 2.13
http://slot.it/Download/oXigen/Firmware/O2ArcHC-0310-200424.zip
http://slot.it/Download/oXigen/Software/O2_Bootloader_0213_2020.zip
The new ARC AIR/PRO firmware is compatible with the Slot.it APP.
What's new? The ARC PRO firmware and the new BL work together to give the user maximum flexibility. Now each button on the ARC PRO controller can be programmed independently.
However there are two main 'modes' for the ARC PRO, and there are two button to set the controller straight away.
After contacting the ARC PRO controller, click on ARC SETUP (1st image) then
1 - for RCSO2: click on the RCSO2 tab to load default for RCSO2
(Car on track: LC button=equiv. to SCP both arrows pressed, Brake=brake
Car in pit lane: LC button=scroll menu down, brake=select)
2 - for oXigen: click on oXigen tab to load default values for oXigen: top button equates to both SCP arrows pressed, bottom button equates to brake (for the car), track call sent after 2".
Other setups are possible as well, such as LC Button=Arrow Up, Brake button= Arrow down.
This is all available via the Bootloader 2.13, but in the future we want to migrate all these things to the APP as it would be more convenient.
![Font Operating system Rectangle Personal computer Screenshot]()
![Font Rectangle Parallel Screenshot Circle]()
We have just released a new RCSO2 friendly version of
1 - firmware for Scalextric ARC PRO 3.10
2 - Bootloader 2.13
http://slot.it/Download/oXigen/Firmware/O2ArcHC-0310-200424.zip
http://slot.it/Download/oXigen/Software/O2_Bootloader_0213_2020.zip
The new ARC AIR/PRO firmware is compatible with the Slot.it APP.
What's new? The ARC PRO firmware and the new BL work together to give the user maximum flexibility. Now each button on the ARC PRO controller can be programmed independently.
However there are two main 'modes' for the ARC PRO, and there are two button to set the controller straight away.
After contacting the ARC PRO controller, click on ARC SETUP (1st image) then
1 - for RCSO2: click on the RCSO2 tab to load default for RCSO2
(Car on track: LC button=equiv. to SCP both arrows pressed, Brake=brake
Car in pit lane: LC button=scroll menu down, brake=select)
2 - for oXigen: click on oXigen tab to load default values for oXigen: top button equates to both SCP arrows pressed, bottom button equates to brake (for the car), track call sent after 2".
Other setups are possible as well, such as LC Button=Arrow Up, Brake button= Arrow down.
This is all available via the Bootloader 2.13, but in the future we want to migrate all these things to the APP as it would be more convenient.
Attachments
1 - 10 of 10 Posts
Join the discussion
