Search results

Sending a PM

I'm on travel until next week so I can't be of much help. I haven't messed with it for a few months.

I was also able to get the 44 parameters at 115200 without the preliminary handshaking. :) That makes the code simpler!

Nope, the internet was just in its infancy when I graduated. Back then it was only used for connecting a few scientific facility together. Voice recognition was just in its beginnings too. It took an 18" rack full of stuff to understand a dozen words. We had to train it by speaking the same...

I agree the code can be more concise. It was the first pass at decoding the data to get it to work. I was simply evolving the code to get it to work. I was going for "function over form" initially. Now that it's working it could certainly be made more concise. Back when I started doing some...

Your "Z" issue may be due to a noise or signal level issue on the 485 data. I ran into an issue with the 485 levels being too low causing issues. Once the levels were corrected data became consistant. Is your Pyserial interface using a hadware UART or is it a bit basher serial port emulator?

For example you read back \x93\x02\x00\x00\x91' The 93 is just a transmission header. Ignore it. The 02 indicates that the next 2 bytes are the data. 00 & 00 are the data. The 91 is the checksum. Here is the code I use to decode the data coming back from the DCS. The DCS response bytes are...

Interesting. I'll have to try 115200 without handshaking the next time I fiddle with that project. Which math? Decoding the values coming back from the DCS??

Interesting. I tried to just send the 44 requests quite a while back and got no responses. What baud rate are you using?

What I found was the handshake to establish communications thru the remote port seems to use/need minimum delays between sending each of the handshake messages to the DCS. The delays are what I measured using a PC with the Remote Monitor software doing the handshaking and an ESP32 sniffing the...

What I have as of today. Will try and mess with the engine code DIP switch tomorrow to try and detect it's codes PC Code Parameter 6 4 ?? 7F C Battery Current D1 B BatteryVoltage 88 17 ?? B1 28 ?? 5B 0 Battleshort A9 D CoolantTemp 46 48 FaultCode 45 48 WarningNumber 44 48...

I have a 1030 so it doesn't have an ECM. The 1060's and up have an ECM and the DCS talks to them over CAN.

I bought a couple of CAN to TTL adapters for looking at the CAN data. I haven't used them yet though. Have been too busy with other projects.

I got that error while poking at my DCS. I seem to remember that possibly my RS-232 levels weren't sufficient to drive/power the B&B RS-232 to RS-485 adapter.

You are correct. The current available TM does not have any info on the wiring of the Remote port.

The remote port pins are NOT labeled with numbers. They are labeled with the letters A thru N. It's a RS-485 port. The cable I'm using. 6150-01-608-2635 PN 04-21227 with the blue RS-485 to RS-232 adapter on it Wiring diagram for the cable above. For Remote Monitoring the RS-485 is on "P2...

I'll be sending updates via PM's to Icesythe7 & R1ckyb0nd so that this thread doesn't become huge 😳

I tweeked my RS-232 sniffer code and there are no longer checksum errors. I also now see what appears as the first requests for real data may be additional handshaking since it's way more than 44 requests. More digging...

Ah, glad you spotted something odd in the code that may explain what I'm seeing. Easy enough to deal with. Request data, ignore the response and request again to get good data. I can work on a timeline of the back and forth between the PC an DCS for each PC request from initial baud rate...

I've been looking at the various time delays between data transmissions from the PC. So far I've seen everything from 7ms to 2 seconds or so during the initial handshaking requests and parameter requests. edit: deleted stuff on bad checksums. Updating in upcoming post The journey continues..