Quote: Originally Posted by
bes51659 
Hi Robby
Thanks for your effort!
I am considering an external antenna according to your previous drawing but I also think there might be a problem with the learning usecase....
I have relearned my system several times (without doctor and config up at the same time) and this time it is wheel 2 that causes me problems. In fact I get only one value at learning and then it is silent. (If I erase data it stays with question marks. See below)
[media]http://web.comhem.se/mulle4/TPMSDoctor.jpg[/media]
It sounds like you have a lazy sensor.
Have you tried in running conditions (driving the car) if the data are updated?
Quote: Originally Posted by
bes51659 
Q1) Could it be that collision makes the ID wrong and then the sensor is never seen again? Or do you have retries? Should I maybe deflate below 1,5Bar and back again to force sensor into "init mode" to get more frequent updates?
As you have already noticed, ther is a 16 bit CRC in the message, so each data collision or bad signal reception will be automatically ignored.
Also, deflating the tire below 1,5Bar and go back again may be helpfull if there is some difficulty during the learnig procedure.
Quote: Originally Posted by
bes51659 
Q2) Why is this? I have observed (by accident) that the abort prompt sometimes goes away before I've even started to deflate the tyre, or VERY soon after I've started. I become very suspicious that a valid learning really has taken place.
Generally, this problem is due to an incorrect cleaning of the USB buffer, the most likely causes are the simultaneous use of several programmes which have direct acces to the device, like TPMS Doctor or RRTMS Plugin and RRTMS Config.
When the "learnig" procedure is performed, any program, with the exception of Config Tool, should to be stopped in order to prevent any interference with the USB buffer.
Sometimes it may be useful to disconnected and reconnect the interface before to perform the learning procedure for each sensor.
What software (and release) gives you this issue?
Quote: Originally Posted by
bes51659 
Q3) If I have a problem with one sensor, do I have to relear all tires or can I just relearn that tire? Unless the ID is already used I don't see why not.
The system doesn't store any identical sensor ID, but you can replace any sensors with a new one (with different ID) without the need to re-perform the procedure for each sensors.
Quote: Originally Posted by
bes51659 
Q4) When I use TPMSDoctor on my 480x800 display the bottom gets cut-off entirely and I do not get access to the buttons at the bottom. I then have to violate the screen resolution with 600x800 (which will give the screen a nasty offset) when I need to use them. Can I please get a smaller layout version? (Am I really the only one that has had problems with this, or am I the only one rude enough to ask?)

I will see what I can do for it.
Quote: Originally Posted by
bes51659 
Once I am at it, I would really like a timer on all sensors in TPMSDoctor to show have many seconds that has passed since last update. Or something else that has the effect that I can get an idee of how well the system is working.
Quote: Originally Posted by
bes51659 
Nice work.
Quote: Originally Posted by
bes51659 
Edit:
I just seen in post one (:-)) that there is a 16 bit CRC in the message so the learning should not get confused by collisioned messages. (Why not show ID also in TPMSDoctor? Or save all traffic in a log file? Is it not sent from pic to PC?) Still, something seems to be wrong with "learning".
Each sensor ID is stored internally to PIC E2PROM only for internal usage and is not possible to read it.
It would require a change in the PIC firmware.
Quote: Originally Posted by
bes51659 
(btw. I only count 12 bytes)
You are right, sorry, my bad.
Quote: Originally Posted by
bes51659 
Edit 2:
Since we know that we will get one transmission every 60s in normal mode we know if messages are lost. This could be used for finding best position for receiver/external antenna. A percentage calculation in TPMSDoctor maybe?
Even this is not possible, because each time the PC does a data request to the PIC, this last always returns the latest information received from the sensors, so is not possible to determine how much time has elapsed from the last RF reception.