SlotForum banner

1 - 18 of 18 Posts

·
Premium Member
Joined
·
4,882 Posts
I have been running a lot of tests recently, specifically looking at how the In-car chip responds to the InCarPro additional commands. Prompted by the recent ID change thread I decided to take a more careful look at ID programming.

Current wisdom is that you set the Control Byte to $01 and all the 6 "Car" Bytes to the new ID required, this is correct but I found this Morning that it misses a trick. Obvious when you think about it....

You can set car ID's individually.
So if you have a car with ID3 and want to reprogram it to ID6. You set the control Byte to $01 as usual, but then instead of setting all of the 6 car Bytes to $06 you just set Car 3 to $06, and set each of the other bytes to not change. Car 1 to 1, 2 to 2 etc.

Note that only the bottom 3 bits are significant / decoded so $03 is interpreted the same as $F3. Also note that setting ID0 is invalid so the car will default back to 1. Would have been nice if this was interpreted as no change...

However what it does mean is that wheras I thought to be "valid" as an ID change packet it needed to have all the car bytes set the same, they can in fact be any value. Which increases the possibility of very small bit errors resulting in an ID change.....

So is this of any use? Well you could just swap two car ID's with all of the cars still on the track. Or rotate cars between races, again all cars on track and just a single command sent.

Rich
 

·
Premium Member
Joined
·
4,882 Posts
This does not affect anything, it is merely an observation, and a feature that could be used in the future. There is no problem with ID change in 1.09 over and above any other version of SSDC.

Rich
 

·
Premium Member
Joined
·
10,109 Posts
We need to understand why the powerbase has been set up to send 5 packets repeating the command if this is to go anywhere. Rich I have asked for data under the NDA, it is coming.
 

·
Premium Member
Joined
·
4,882 Posts
Don't see why we need to understand that, for this to go anywhere, if there is anywhere for this to go? I think it's just overkill, to ensure that the command gets there. Definitely not needed to change the ID, in testing I just send the command once, and it works every time.

I think however that InCarPro waits for the second send before updating, and also checks that the first 4 cars are set to the same ID before allowing the ID change. (Only 4 cars, as opposed to 6, for compatibility with the 4 Car Powerbase that only sets the ID for the first 4 cars). So ICP in it's current form would not work with individual car ID setting. However this is one of it's enhancements that could make ICP less prone to ID change.

Rich
 

·
Greg Gaub
Joined
·
14,661 Posts
QUOTE (RichG @ 22 Feb 2012, 03:38) <{POST_SNAPBACK}>Or rotate cars between races, again all cars on track and just a single command sent.

OMG! That would be EPIC! We could save so much time through a race night not having to individually re-ID cars when we rotate. I would love to leave the cars on, and have SSDC reassign all the cars to their new ID when I load the next race. Oh man... that would be so awesome.

I love it when you guys fiddle and experiment. It usually ends up in some revelation like that, putting us on the way toward cool new features! Though it's kind of sad to know this was possible and Hornby never made use of it.
 

·
Premium Member
Joined
·
1,009 Posts
Interesting find Rich. I remember wondering if this was a possibility the first time I studied the rails protocol on MIH's website.

So presumably the program packet could be used with IDs kept as they are (1->1, 2->2 etc) and the 5 ignored bits per ID could be used by ICP for switching lights and things rather than using the 'F7' aux packet?

I guess it depends if the standard chips would write their ID to the non volatile memory even if it was unchanged, as writing to that once or twice a second would be fairly sub-optimal for the life of it...

Out of curiosity what happens if you try and set the ID to 7?
 

·
Premium Member
Joined
·
10,109 Posts
QUOTE (RichG @ 22 Feb 2012, 15:31) <{POST_SNAPBACK}>Don't see why we need to understand that, for this to go anywhere, if there is anywhere for this to go? I think it's just overkill, to ensure that the command gets there. Definitely not needed to change the ID, in testing I just send the command once, and it works every time.

I guess I'm just fed up guessing at what is or isn't supposed to happen coupled with poor implementation causing artifacts. Getting the code should tell us exactly what happens when and saves us cocking up by missing a hidden mode or something that we are currently blind to.
 

·
Premium Member
Joined
·
10,109 Posts
QUOTE (asjwood @ 22 Feb 2012, 20:56) <{POST_SNAPBACK}>Interesting find Rich. I remember wondering if this was a possibility the first time I studied the rails protocol on MIH's website.

So presumably the program packet could be used with IDs kept as they are (1->1, 2->2 etc) and the 5 ignored bits per ID could be used by ICP for switching lights and things rather than using the 'F7' aux packet?

I guess it depends if the standard chips would write their ID to the non volatile memory even if it was unchanged, as writing to that once or twice a second would be fairly sub-optimal for the life of it...

Out of curiosity what happens if you try and set the ID to 7?


We did some testing with cars set at 7 and the system fell apart. Other cars lost control, so there is something else that we don't understand. When we have the info then maybe that will become a possibility, but at this moment I doubt it.

For me with the luxury of MIH chipped cars and the facility to turn lights on and off, I love this as a cool feature and it is cool because you can do it when you are driving. If you merged it into the ID'ing packets then we would lose that capability as I am fairly certain that it would be too risky to send ID packets during a race.
 

·
Andrew Wallace
Joined
·
1,100 Posts
FWIW - I think that the AUX packet should stay. Perhaps we change the header byte, but there is no way that we can make the current packet format extensible enough to support future requirements. Yes we can all try and think up clever ways of packing a bit in here or there, but the AUX packet gives us room to grow.
 

·
Premium Member
Joined
·
4,882 Posts
Happy with the Aux Packet, happier still if we avoid using either of the bottom two bits, in particular both of them together, for the control Byte.
Now that we know that $00 is an idle packet, it makes it much safer to build the Aux packet control Byte on that..

I have tested setting ID 7 and there were only two possibilities. 1 because it is invalid or 6 because 7 includes all the bits to set 6. It programmed to 6.

Rich
 

·
Premium Member
Joined
·
10,109 Posts
If i remember correctly as it was a while ago it wasn't just that the car didnt accept the ID it was that having an ID7 data packet caused the other cars to fault.
 

·
Premium Member
Joined
·
4,882 Posts
We are at crossed purposes. I am talking about sending a 7 in a Car ID packet (Command $01) and you are talking about sending out a drive packet (Command $02) for a 7th car. Which I could imagine could cause all sorts of havoc.


Rich
 

·
Premium Member
Joined
·
1,688 Posts
Just when I think I'm getting to know a bit about this hobby I go and read a thread like this and "KA-POW" it's back to feeling dumb again, I'm glad you blokes know what your talking about, sounds like there maybe something interesting at the end of this rainbow.
 
1 - 18 of 18 Posts
Top