Originally Posted by
acannell
palm pilots!! do you still have that setup somewhere?
The Palm Pilot setup takes me down memory lane...I'm not sure if I still have a machine with the source code still on it, I know that I wrote it up in HB++. The Palm Pilot I used to have was a Tungsten T3, which had a larger screen and Bluetooth. I used a serial cable to connect to my SCI to RS232 adapter to communicate to the Logic Module, and a Serial to Bluetooth adapter connected to my LM-1 and LMA-3 Auxbox.
The app on the palm pilot handled the LM communications (check for low-speed, send 0x12 to switch to high-speed, then start requesting points) over the serial connection, and used Bluetooth to receive the Innovate WB and sensor data stream. The data was displayed on the screen, and when WOT was detected, it logged the LM and Wideband data to an HTML table file on an SD card, and I used the browser to view the log files.
Originally Posted by
wowzer
warren - how do you handle the LM baud rates?
Morris, here is a simplified overview of the state machine I'm using for initializing communications with the LM:
NOTE: The Comm port is open in high speed mode (7680 baud) at all times except when sending 0x12 bytes to signal the LM to switch from low-speed mode (976 baud) to high speed mode.
1. Open the comm port in high speed mode (7680 baud), set a timer and set state to LowSpeedCheck.
2. Regardless of state, when bytes are received on the serial port, save the contents of the buffer and keep track of how many bytes have been received during the time period, then zero the count after checking for the next time interval.
3. Regardless of state, if no bytes are received during the timer period, assume communication has been lost, close and reopen the port in high-speed mode and go back to LowSpeedCheck state.
4. LowSpeedCheck state:
a. If the LM is in low-speed mode (976 baud), it will be sending a stream of 0x12 bytes. I figured out that a stream of 0x12 bytes sent at 976 baud looks like a stream of 0x80 0x00 pairs when received at 7680 baud, so I always receive at 7680 baud - this simplified the code and made it more reliable when reconnecting after restarting the car or toggling the ignition.
b. If I see a stream of 0x80 0x00 pairs the LM is in low speed mode. Close the comm port, reopen in low-speed mode (976 baud), send three 0x12 bytes, and close and reopen the comm port in high-speed mode (7680 baud).
c. If no 0x80 0x0 pairs, send three 0x12 bytes in high-speed mode, which will cause the LM to send a string of 0x12 bytes.
d. If I see a stream of 0x12 bytes, I know for sure the LM is in high-speed mode and ready to take points requests, go to Connected state
5. Connected state:
a. Go down the list of data point addresses, sending the data point address, throwing away the first byte received after sending the request, and saving the second byte received as the value to convert for display/logging.
This is where I am having some intermittent bogus data returned due to a timing problem. Sometimes the second byte received may still be for the previous point instead of the point I just requested.
I tried using the OTC scanner approach which sends the address, receives the first byte, sends the address again, then uses the first byte received after sending the second request as the value of the data point. When I made my code work that way, accuracy improved, but it still occasionally gets the bogus previous value.
I could to a third request/receive cycle, but it would slow down the number of frames I can process per second.
b. When all points in a frame have been requested, scale the points in the frame and display or log them.
c. Lather, rinse, repeat.