[injectorman]

Hi Guys.
Ive made a special thread on this issue.
Unfortunately around 10% of car decoders were manufactured with a wrong value resistor in the RF transmit circuitry.
These car decoders will run fine throttle wise, but have issues sending consistant car dat 100% of the time.
This results in around a 20% failure rate in faulty lane changing and lapcounting.

Run the car data program, the car should send 10 updates per second CONSISTANTLY.
These car decoders often have trouble reflashing, because sending data is part of the reflash process.

Do not waste time or get frustrated. Simply return for analysis and replacement.

The factory will replace these once I know how many to send back.

PM me for the address.

Rick

 

[Merc_A]

Rick, you wrote this trick to check whether the car decoder is faulty:

The way to easily tell these is to run the Car Data program found in the V4.4 car decoder file. Run the program. Place car on rails with tyres off ground and rev the car once to establish communication. Now let rear tyres come to a stop yet maintaining power from rails. The data flow coming in should be ten times per second without any hiccups. A hiccup is easy to see actually.

All my 20 chipped cars do the following when running your test (i have 20 chipped cars so far, 2 used but turned down chips and 28 chips still in the box):
revving the car and stop - data comes in at 10 lines / second (you can see a grey field running down the list at about this speed).
This goes on for say 5 seconds, after that the speed of data flow falls back (you can see the grey field running down at a consistent yet lower speed).
If you rev up the car, data speed goes up tot a consistent 10 lines / second again.

So the data comes in smoothly, but if you don't touch the controller the speed of data flow goes down after 5 seconds. I reckon this is normal and no hiccup right?
I think this because the data flow itself can be quick (when applying power and the 5 seconds after power down) or slower, but always consistent in a smooth pace.

I suppose what you mean by a hiccup is a visible distortion in this data flow?

BTW out of the 20 chipped cars i now have 2 suspect chips: one that would not reflash anymore, even after 5 tries and one chip giving no consistent lap counts.
I don't have the time really to check on my remaining unused 28 chips still in the box, but warranty is not eternal of course.
So is there a quick way to run a test on the chips themselves?
Like not fitting in a car, but simply applying power to the braid side of the chips (soft green wires) and see if it sends data and/ of can be reflashed from pc?
Or do you have to fit a motor on the motor side (blue / white wires) to be able to do this test?

Let me know if i can perform this test procedure, so i can tell how many faulty chips i might have.

Merc

 

[injectorman]

Mostly correct Merc,
When revving the motor the data is flowing so fast you cant see it, maybe 100 times per second.
After taking finger off trigger the car will take a couple of seconds to revert to ten updates per second. This is the bit that should flow nicely. You can check the time stamps, each entry will be approx 1/10th second +or - say 10%, but overall 10 entries should come in in one second + or - a hundreth of a second.
So you have 2 in 20? That sounds about right, 10%, of course some will have none, others more.

I have decided to sack the company involved so they will not be getting my business from now on but of course I take full resposibility

These things happen but no excuses.

Quick check is both braid wires to 12V and reflash to V4.4. Thats not to say this is the best way but its a quick way to grab the obvious ones.

Rick

 

[Merc_A]

ah ok Rick, all is clear now, tnx

I'll run through my batch of decoders shortly, using the method as you pointed out.

Merc

 

[injectorman]

The default ID of a new chip is 1 so why not try to get car data from by activating a controller.

Rick

 

[Merc_A]

Exactly, that's what i was thinking - powering up a controller gives a reaction in the car data program.
only i was not sure if the data would come out right if there's no motor connected to the blue/white wires, but now you say it does, the better.

This might as well be a good standard car decoder check, before fitting it in a car - before all the hassle of connecting wires and fitting the sensor, i can see if the chip is def ok.

Merc

 

[Merc_A]

I've run through all my 20 chipped cars again, and checked them with the car data program.
I checked the time stamps carefully for each car, and I noticed that many cars (to be precise 11 of them) showed an occasional 1/10th jump over one timestamp.
I watched the data flow and looked closely for a regular series of .1-- .2-- .3-- .4-- .5-- .6-- .7-- .8-- .9-- .0-- intervals.
Occasionally it skips one of the 1/10 intervals. What i mean by this is as follows (i'll write down a typical second of time stamps as i witnessed):

.093
.187
.278
.381
.490
.578
.760
.889
.006

You see the skip between .578 and .760? It missed one stamp somewhere in the .600's
It's a hardly visible skip with the eye, the grey field seems to flow consistently for the eye. It seems to halt for a fraction, then moves consistently again.

This happens quite often. Do you consider this a hiccup? 11 of my 20 chipped cars show this pattern occasionally.

Merc

 

[injectorman]

Hi Merc
I really dont know yet. That data is mainly used for fuel. The important question is do the cars count laps? If so probably not a concern. I really dont know until I get some more clues. Maybe Ill cut back on data a bit.
Its also our first go at writing the software, Im surprised it works so well straight up but maybe theres room for improvement. Early days still.

Rick

 

[Merc_A]

Lap counting is still not consistent, i tried all my cars tonight.

A number of my cars have counted the laps 100% not a single missed lap.
I have to add: all modern scalextric cars (and one Fly) are in this group - but this can be coincidence of course.
The other cars do miss laps at times. It can be at speed, it can be slow.
Sometimes when missing a lap at speed and repeated driving slowly, it does count the lap after all.
Sometimes it refuses to count a lap for 3, 4 tries, no matter i'm repeatedly going over the LB slow or fast.

I've tried power off / on, reboot laptop, take out the dongle cable and in again - at times it seemed like this type of rebooting the system seemed to improve things.
I haven't had trouble with reflashing car decoders - except for 2 cars where i had to repeat the reflashing procedure because it kept hanging, but after that reflashing the chip was succesful.

Other pattern i noticed: missed laps for some cars only at lane 1, for other cars only at lane 2.
That made me think of a problem with the LB, leds or whatever.
However, i got it reflashed and resetup as LB 0 without any problem.
After all, there are cars counting laps without any problems.
I tried antenna position.
One SCX car did not count laps well, missed a lot of laps (but could see all the LB's well in the car data program)
After repositioning the antenna it suddenly did all its laps without missing one.
That was y'day - today the car did show its old pattern again.

Can there be a glitch in the dongle? That dongle remains a black box to me. How it hangs, antenna reception, noise?
Or is it a possibility that for instance modern scalextric cars result in clean data without noise, and other cars might somehow influence the cleanliness of sent data?
However, i have a SCX missing laps occasionally, a teamslot with brand new slot.it motor...
Or what i figured: it still can be a software thing. - if computing is slow that might compromise data processing and displaying.

Bottom line, as i compared the cars in the car data program:
ALL cars do pick up ALL the correct LB numbers. No car missed any LC up til now, and no car missed LB 0 when passing over it.
LB0 always shows up correctly in the "last LB" list - there was no single error in this, lap after lap, car after car.
I haven't had any faulty non existing "LB 31" data since i swapped the motor of a car that had this issue.
So I concluded: The signal is picked up and comes through on screen. This car data regarding the picking up and sending LB # is flawless.
Faulty leds are crossed out. all leds /sensors work.

It just the darned lapcounting... Somehow the 20 lines of "Last LB 0" text that pop up does not process to a correct counted lap consistently.

Merc

p.s. what i described in my earlier post regarding the 1/10 the skips you don't confirm as a true hiccup right? Trying to figure out if the chips are faulty or not, and i'm not totally sure if the skips in timestamps are a proof of that.
Reading your first advice, i started thinking it is a hiccup - hence a faulty chip. But i reckon what you consider a true hiccup of a faulty chip looks different?

 

[injectorman]

Hmmmm thinking, thinking.
I still think its chip specific, in other words some car decoders are fine, some have the wrong resistor.
In regard to lane changing the cars antenna is not even 500 mm away to the LB antenna. With lapcounting it has to travel further, ie across room.

Theres also a possible software fix for this. Im talking to John now about it.

It could be LB specific, but I seriiously doubt it, as you say the LCs work fine. All the LB does it put out a code in regard to lane changing, it doesnt have anything to do with RF.

Could also be car specifi. If the decoders remain in the cars during tests there car specific issues to be considered. ie is the car sensor correctly aligned. By the look of the photos the ones I seen looked ok. Dont spend too much time. I can check these quickly and easily here on my test track.

Rick

 

[Merc_A]

Is the wrong resistor visible / can it be detected by close visual inspection? Is it visually different from the correct resistor? (different part # or factory code?)
If so, try uploading a high res picture.

Merc

 

[injectorman]

Hi Guys.

Good idea Ill ask John to supply details. Its actually a capacitor I just found out.

Good news these we can change the capacitor and ship it straight back, phew!

Rick

 

[injectorman]

Ok I know more now, some capacitors must be faulty, not the wreong type. And John uses the oscilloscope to determine which ones are suspect. So I cant show you a part number sorry.