SlotForum banner

O20C1 Chip with SSD firmware.

850 Views 35 Replies 6 Participants Last post by  Klitgaard
Excited to read about Oxigen 4.0 and not having tried Oxigen before I got some O201C1 chip and a SCP3 controller.
For now we run a Scalextric ARC PRO with Magic app. The plan was to start running these chip as SSD with Slot.it FW 3.16B as this should emulate SSD chip.

Later we would properly go full Oxigen, but wait for 4.0.

The issue here is that in - ARC / Magic/ Std. controller - setup the car apparently goes into programming mode after 12 seconds.
This happends before start, if we do not take off within 12 seconds, but also under YF, if we do not restart within 12 seconds, the car will go into programming mode.
As long as the car stays on the track so connection is not broken, there is no issue. But as soon as the O20C1 chipped car has left the track for more than 12 seconds it will go into programming mode.

I am aware that the chip needs some kind of trigger to go into programming mode. But this means that the O20C1 is not as compatible with SSD as i got the impression of.

Maybe someone can verify my observations.
  • Like
Reactions: 1
1 - 20 of 36 Posts
I haven't tried this, and I don't know if it will cause problems with the RMS program... but what if you were to press and release the brake and/or LC button with no more than 12 seconds between presses? The chip should receive this signal that is sent to it and since the signal is changing, hopefully keep it in "active" mode, rather than dropping into programming mode?
Hi MrF
Thanks for the suggestions.
Brake is our fuel filling trigger, so that will not be one to use. I will give LC a try, but I do think this is a bug that slot it should look at.
@Slot.it maybe Maurizio/Slot.it should be made aware of this.
It is the first time I hear about this behaviour.
To me sounds like a bug: the code that put the chip in programming mode if the chip is not paired with a controller in oXigen mode should have another condition for triggering its execution if the chip is operating in SSD/Carrera.
  • Like
Reactions: 1
I hate to suggest it, but they could always have it require the hall sensor to be installed, and use the magnet trick to trigger DFU mode to change the firmware.

I certainly don't know enough about what the firmware and hardware is capable of, but even if you managed to keep it from losing power too long as it passes over lane changers, if your car happens to land on a dead spot during a yellow flag, you wouldn't be able to say "only reset if power has been lost" either. Any number of button combinations from a controller could happen while driving the car, so you can't really use that to trigger programming mode.

If the chip can tell the difference between pure DC and the rectified AC, then maybe have it only go into programming mode when put on DC? But then people would have to have some kind of thing to put the car on with enough DC to wake up the chip and keep it alive while programming. A 9v battery can do this, but it would be awkward to hold in position while fiddling with the app.

I look forward to the results of the testing. If this were being used on an APB and RCS64, then you'd have to watch the screen to make sure you didn't take away a damage point, or mark yourself ready before you're actually ready. ;-)

Hi MrF
Thanks for the suggestions.
Brake is our fuel filling trigger, so that will not be one to use. I will give LC a try, but I do think this is a bug that slot it should look at.
Does it trigger as soon as you press the brake, or do you have to hold the brake to make it refuel? I was not suggesting to hold the button(s) down, but just to click them every few seconds.
See less See more
Yes, I was thinking about the same with the hall sensors/magnet trick.
It is not ideal but better than having to press buttons while in track calls.
Yeah. I also just realized that button pressing probably wouldn't work with the APB and RCS64, because I don't think it would be sending control signals to the track/car during YF or any other unpowered pre/race mode.
There’s a documented procedure for entering BLE mode on the C1 chip (that I think applies to the case where the chip has SSD firmware):
How to start BLE so that it can be contacted with the Slot.it app:
if your chip is:
  • New (factory fresh, firmware 3.10 and later)…
  • oXigen…
  • SSD and D132: leave the chip on SSD track for 10” without pulling the controller’s trigger, then press the lane change button for 2".
Once this is done, the chip can be contacted by the Slot.it app. Press ‘Connect’.
It’s this that, in my mind, doesn’t work as it should.

@Slot.it maybe Maurizio/Slot.it should be made aware of this.
It is the first time I hear about this behaviour.
I’ve mentioned this a couple of times, and this little problem has actually celebrated its first birthday. But yes, it’s easy that things get lost in this forum, and I’m positive. We, the community, simply need to apply some modern software practices together with slot.it, and we’ll be alright. I’ve wanted to start that discussion for a while, but have been holding back in order for the dust to settle around the last firmware updates, and let the everyone involved in oXigen 4.0 to focus on that first.
There will be never settled dust here...oXigen is evolving all the time.
The most recent bug fix to the 3.16 firmware was tested first on a 4.0 firmware. :)

And, somehow, I completely missed, or more likely forgotten all about, the need to hold the LC button to put it into app mode. So yeah, if they think it works like that, but it clearly does not, then it could use some fixing. I wonder if one of the older SSD firmware works. It might be worth testing with other/older SSD firmware to see if the problem has always been there, or started at some point along the way. Being able to tell slot.it that the problem appeared in a certain version would make fixing it quicker.

A link to the previous topic on this issue would be appreciated. I have a feeling I commented on it then, as well. LOL

Also, RIP my memory. :(
I think this bug was introduced in the 3.16b SSD firmware. I haven’t tried any earlier version myself, but as it’s so easy to verify and be affected by, then my guess is that it wasn’t there before.

Here’s some links to threads and posts where this has been discussed:

oXigen 4.0

Anyway, it has indirectly been acknowledged by slot.it, so I’m sure it will be fixed sooner or later!
  • Helpful
Reactions: 1
That’s the reason I stopped using the O201c chip. If it were fixed I could use it for both oXigen and ssd. As it stands I can’t. That plus the 2 dead chips out of the 4 that I purchased.

Mike M.
  • Sad
Reactions: 1
the 2 dead chips out of the 4 that I purchased.
Didn't Alan replace those? If not, what was his reasoning?
Anyway, it has indirectly been acknowledged by slot.it, so I’m sure it will be fixed sooner or later!
One should be carefull giving advise in such cases.....
But, if ressource are limited, maybe it would be better to concentrate efforts on fixing already released products, and if necessary, put new ones on hold. 😉
  • Like
Reactions: 2
Didn't Alan replace those? If not, what was his reasoning?
He told me to send them to slot.it.

Mike M.
  • Like
Reactions: 1
He told me to send them to slot.it.
A small package like that would cost a lot less to ship to them than two more chips would. ;)
Maybe someone can verify my observations.
I dug out the necessary hardware to test this, and I could not get any cars to go into DFU mode on a live SSD track, with or without the MAGIC app running a race or even being connected.

I'd like to replicate this, and it's clearly not hard to do, but maybe I'm not testing the correct firmware versions. What firmware are you guys using that has this problem? If not the most recent (SSD 316B) firmware, then have you tested it with that firmware?

Edit: I checked the other thread, and it appears you have been using SSD 316B. I wonder if this has anything to do with the fact that most of my chips primarily get updated to the latest O2 firmware, and so have been changed from the latest O2 firmware to the latest SSD firmware? I guess that's worth a try for anyone who would not have done that.

I did find a couple other issues that I believe are app related, and reported those to slot.it, but I don't think those issues are related to this.
I’ve mentioned this a couple of times, and this little problem has actually celebrated its first birthday. But yes, it’s easy that things get lost in this forum, and I’m positive. We, the community, simply need to apply some modern software practices together with slot.it, and we’ll be alright. I’ve wanted to start that discussion for a while, but have been holding back in order for the dust to settle around the last firmware updates, and let the everyone involved in oXigen 4.0 to focus on that first.
I did find a couple other issues that I believe are app related, and reported those to slot.it, but I don't think those issues are related to this.
What I mean with the above is that we need some proper issue tracking and release management in place. Simply something similar to what’s is available out-of-the-box in e.g. GitHub, i.e. public threads that are focused on issues, and release documentation that links to those issues when things get fixed.

I’m not saying that oXigen should go open-source, but could use an official GitHub account for the above, or simply a subsection to this section of the forum, and also document in the firmware .zip files and the app stores what have been changed.

Personally, I’ve a bit given up spending too much time on detailing issues I or other find and writing about them here, because I don’t get any response on them, and I don’t see others getting any response as well. But I’ve now realized that this section of the forum doesn’t work as I think it does. It’s NOT an official channel that gets monitored for issues in the oXigen products; it more occasionally/randomly works that way (but without any feedback). It also so hard to know what problems others already have reported, and if there’s any work-around to those problems (or if they already have been solved). I think some of the frustration we see come from this (in addition to having an issue, of course).

But I’m positive, I think this can be turned around. It would be good that have some simple feedback loop in place, some simple software practices, a bit more structure, and we should be in a better shape. It would of course be good to have that in place before oXigen 4.0, as there will be a lot of issues there, but I guess this need to be discussed and implemented after that release.

OK, this got me a bit more motivated again. I’ve been waiting for a new iOS app, I’ve always needed to use my wife’s Android phone to be able to change firmwares. But now that we have a new iOS version, it may be time to look at this again. It may take a couple of weeks, but I’ll play with the firmwares as you suggested, Greg, and see if that solves anything.
See less See more
  • Like
Reactions: 2
Hi

I have been using the newest C chip firmware for the SSD platform. And I always get into the situation, that the C chip go into BT mode, when I am waiting for the light to go out when using the C chip with my Arc Pro powerbase together with Magic App-en.

I am also seeing this issue with the same C chip and same firmware on our club track using the C7042 together with PcLap counter, RCS64. And I have been trying with difference C chips, and the result is the same. The C chip go into BT mode when waiting for the light to go out.
  • Like
  • Sad
Reactions: 2
1 - 20 of 36 Posts
Top