• We recently switched our forum platform. If you experience any issues please email support@crystalfontz.com

Scab Temp Sensor Refresh Rate

Heffo

New member
Hi,

I got my new CF635 and a chain of 10 Temp sensors.

I have noticed there is a noticeable delay refreshing the screens & custom chars while I have the chain of sensors connected.

It seems to me like CC2 is polling all the sensors one after the other in a batch.

Would it be possible to tweak the sensor polling so that it doesn't hit the refresh on the screen as hard? Maybe poll a couple of sensors, then let the screen get some traffic, then some more sensors, etc... or possibly poll the sensors during idle time.
Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.
 

CF Tech

Administrator
The CFA-635 polls the sensors and reports the results when the conversion is complete. CC2 has very little to do with it, CC2 would just receive the temperature report packets in its incoming buffer.

The temperature reports are "spaced". If you have all 32 connected, one report is generated every 1/32 of a second continuously—a full cycle of all 32 being read every second. With 10 connected, you will see 10 come in spaced every 1/32 second, then 22 empty 1/32 second slots. So even though the 10 you see look like a "burst" they are spaced 1/32 second apart.

I do not know why CC2 display performance would interact with the temperature reporting, we will have to get CC Admin to look into it.
 

CF Mark

Administrator
This has been an ongoing problem for a very long time now.

Its a problem with LCD update packets getting dropped when temp sensor packets are sent from the LCD module to the PC.

I have put many many hours into trying to work out the problem and have been able to minimise its effects, but not fix it completley.
 

Heffo

New member
Perhaps it may be an issue on the display side.

Maybe there is a problem in the RS-232 driver code in the LCDs microcontroller that corrupts/looses incoming data while an outbound transfer is in progress.
 

CF Tech

Administrator
I do not think so. We wrote a utility that hammers the ever livin' stuffing out of the display's communications interface and it does not lose packets. It has been a while since I tested that aspect though -- maybe a bug crept in. Probably time to run it again.
 

Heffo

New member
I know the DOW sensors are sampled at 1/32 of a second. But from what I noticed in the 635 wintest packet debugger is all the sensors data is flooded out the serial interface in a single large batch.

Now on a completely standard RS-232 interface that isn't an issue since it's a 2-wire bus (no bus collisions for TX and RX data on a single wire)

The USB <--> RS-232 converter though makes things a little more interesting, since that the same bus is used for data going both directions.

The way I see it, while the 635 is flooding the USB bus with sensor data, CC2 has to wait to send the display the updated screen data. Since the USB bus is buffered no packets are dropped but a delay is added.

Since I don't have a serial version of the 635 I can't test this theory. My suggestion would be to load a non-usb 635 up with a full complement of DOW temp sensors and see if it bogs down on the screen updates.
 

CF Mark

Administrator
Nice theory, but it does still happen with the serial 633s & 631s that also have the same problem.

If it is the LCD dorpping the packets (which i think it is), it has to be while the LCD is querying the sensors or while compiling and sending the packets.
It should be while querying the sensors since RPM report packets do not cause the problem.

Then again it could still be something werid going on with my packet handling code in CC2.
The fact that it only happens with temp reporting enabled and not RPM reporting leads me to believe it is a LCD problem though.
 

CF Tech

Administrator
software guy: "It is the hardware."
hardware guy: "It is the software."



We will be getting together within a month or two, and hammering out this issue is a priority.

I think that the bandwidth of the USB is so much greater than the serial, plus the USB chip has buffering, that the simultaneous transfers should not be an issue.
 

Heffo

New member
CF Tech said:
software guy: "It is the hardware."
hardware guy: "It is the software."
Heh, imagine the arguments when you are both the hardware guy and the software guy!
 
Top