[*sean*]

Original plan was to finish my tester and test the existing valve in-car. Since I'm waiting for a part, I pulled the best valve of the bunch and put it in the car. Pulled the old valve out and this is what I got starting with a usable valve for comparison. The plots are from fully closed (bottom) to fully open and back. The center tap of the pot is pulled up with a 10K resistor to ensure that any intermittent loss of contact is readily apparent.

Usable valve (not from car):

Bad valve (from car):

This EGR valve is SHOT. Based on my capture, I think the car is moving the injector pulse width attempting to adjust for the error. (This is something I want to test someday).

I have put the best of the valves I had into the car to see how it performs.

 

[*sean*]

MPG increase: about 5-10 MPG.

It still lacks some power and misses slightly in lean burn. So the sorting out continues.

 

[*sean*]

Put an electrolytic cap across the 12V supply to see if it would clean up the scope signal on my EGR valve tester; then decided to see how much it would smooth out the analog input. I expected way too much filtering, as it was a big cap; I just wanted to see what happened. What do you think the effect was?

A. No effect, signal the same
B. A lot of filtering, but signal discernable
C. Flat line

Spoiler

The answer is C, Flat Line, because dumping 12V collected from the power supply into the analog input made the MCU kaputt! Oops! Ordered more to replace it.

 

[tervic]

No idea about that so I'll propose

D) Great big flash and bang!

 

[*sean*]

No idea about that so I'll propose

D) Great big flash and bang!

Well, the capacitor was pretty small, but you have the right idea!!!!

 

[FormulaLosAngeles]

I will pay you for log files of normal and envelope operation
so that I can have a baseline reference for aftermarket nemisis and speeduino ecus and crazy mods that I am working on.

 

[*sean*]

I will pay you for log files of normal and envelope operation
so that I can have a baseline reference for aftermarket nemisis and speeduino ecus and crazy mods that I am working on.

Thanks, but I must decline. My goal is simply to sort out this Citrus and restore it to its original running condition. Rather than throw a bunch of money at replacing parts willy-nilly, I am putting some thought into how I might build tools, like the EGR valve tester and what is essentially a high resolution OBD2 live data stream viewer, that can help me quickly isolate a problem.

 

[jsloden]

My 2000 manual is having similar symptoms to what you were describing in your original post. Low power, especially in lean burn, low mpg 44-45, jerks coming out of lean burn etc... I'm wondering if your car ever through a CEL or code at all? Mine hasn't. I would assume if the EGR was bad enough it would turn on the CEL. I'm in the process of trying to get the egr plate off to clean it but the nut that's hard to get at under the intake has been rounded off by a previous owner so that's an issue. Great work constructing the equipment by the way.

 

[*sean*]

@jsloden I did not get a CEL for the lean burn problems specifically, which is kind of annoying because I know it would not be hard for Honda to have detected an intermittent EGR valve. When they are intermittent it appears that it negatively impacts fueling. I have a number of theories about harm this might cause which I'm holding back until I have a chance to investigate more. It's pretty easy to check for an intermittent wiper in the EGR valve with a variable power supply, voltmeter and resistor, but a bit more difficult to check for non-linearity of motion due to worn guide bearings.

The LAF sensor behaves like you say particularly if you have the wrong kind of sensor installed. When I was sorting out my red car, I ended up replacing the LAF sensor and EGR valve, and other things that I had no idea whether or not they helped. The point of this effort is to set up the car so I can precisely measure its performance (at least the best that I can without an actual dynometer - I have thought about buying an old smog check dyno) and then do A/B tests. For example, I hope to make high resolution measurements of the timing signals and LAF sensor output to see if I can find issues with a particular cylinder...

 

[jsloden]

When I first purchased the car it was getting low 40's. I started going through the checklist. It's got the re92 tires at 45 psi, I had to purchase the outside air temp sensor and pigtail from a pull a part due to mine being missing. This got the auto start-stop working. I checked the spark plugs and they are the correct plugs and indexed correctly. Aero panels are in place. I also had a rear brake that was dragging. This has been corrected. This tank I'm at just a little over 45mpg so far. The battery seems to be in good shape but I would still like to grid charge it to make sure. I am looking at purchasing the rb batteries charger. The egr plate and valve is about all I have left. The o2 sensors are new and are the correct ntk's.

 

[*sean*]

I'm taking a quick detour making an Arduino-based LTO Battery Monitor which requires use of a CAN library. I am reminded of the real reason I'm ditching CAN for my car projects and going with RS-485: on Arduino the happy path is overgrown with weeds: https://forum.arduino.cc/t/how-to-select-the-best-possible-library-for-can/694577/8

On Pi, it's soooo simple: $ candump can0
and, to beta.openai.com/playground:
"Write me a python app that takes CAN messages from CAN0 and ..."

But Pis take a while to boot and need either custom power hardware or tricks with read-only filesystems to not risk data corruption with a sudden power loss should they happen to be writing to disk during power loss.

 

[*sean*]

I suppose this LTO Battery Monitor isn't strictly related to sorting out the Citrus except that someday, dropping four LTO packs in the thing is gonna happen.

I just spent the last three hours pulling out my hair trying to find out why the @(#$ thing would send CAN messages during a test. I'm using an ESP32-C3 called a Seeed Xiao ESP32C3 that includes Bluetooth 5 and is tiny. Dragged out the logic analyzer to try to figure out what the *@#( was wrong. At boot I could see SPI traffic from the ESP32C3 but no chip select pin activity???? Turns out that unlike the Uno, which names pins by numbers (ie, for pin 3 you do digitalWrite(3, HIGH)), this thing uses macro names (I think that's how they're implemented) like D3.

Now time to hook it up to some packs.

 

[*sean*]

Got the CAN bus data flowing. Yay! Next is output to a display. (And, found a bad cell. Niiiiiice.)

 

[*sean*]

Oh THIS!!!! vvvvv

If you're not trying do theming, this is by far the easiest way to write an Android or iOS app. Probably easier than writing UI code for an Arduino or Pi with a built-in display. And doesn't everyone have a spare phone laying around? And aren't phone holders for cars available for $5 at any dollar store?

If you have ever played with Scratch and done any kind of drag-and-drop UI building, then this and Googling "MIT AppInventer <thing you want to accomplish>" will get you there with minimum learning curve. If not, I'm sure there are a million YouTube videos to set you straight.

This part of the LTO Battery Voltage side trip is actually right on for sorting the Citrus, because I need this for monitoring certain Citrus stuff with the tools I'm building.

 

[*sean*]

This is an example of the "code" used to select and open a Bluetooth Serial Port Profile connection in MIT App Inventor (not completely tested):

After all that, found out that I went down the wrong path trying to write a Bluetooth Serial Port Profile interface for a device that only supports Bluetooth LE 5 (who woulda known it doesn't support classic Bluetooth?) To get a quick idea of what I might need in my Arduino sketch, I asked OpenAI:

Based on past experience, I don't think the code it generated will work out of the box, but usually it gets 90% of the way there. This is much, much faster than watching YouTube videos, trying to pick out decent tutorials in a sea of SEO that end up not doing what you want, etc.

The following instructions work on a modern Android phone and show how to list and connect to a Bluetooth LE device:

https://iot.appinventor.mit.edu/assets/howtos/MIT_App_Inventor_Basic_Connection.pdf

They don't show how to talk to the device once connected.

 

[*sean*]

The example code for the Seeed Xiao ESP32-C3 is working, and the MIT App studio Android app can see it!!!

 

[*sean*]

I am capturing voltages via CAN, sending via BLE and the phone is displaying them. I like this.

The hardware, buttoned up: four wires, 12V in and CAN A/B:

Good enough for a while. Things I need to do:

App, Arduino:

• #1: Quick-glance meter showing current high and low cells (essentially shows capacity and imbalance in one place), with colors
• "Ignore" instruction so bypassed cells are not counted in hi/low
• User-settable high and low alarms, drag across main screen
• Bluetooth disconnect alarm
• Automatic Bluetooth reconnect
• Alarm audio
• Switch to React native?

Hardware:

• Switch to nRF52840 and implement security features
• Add IMA current sense and pack contactor disconnect relay/FET
• Add grid charge disconnect relay/FET

Present phone UI; big space in middle for future gauge:

Voltage settings screen:

Alarm settings screen:

Rudimentary connection screen, to go away:

 

[*sean*]

I have a confession: I've (still) never used a USB-C cable for data transmission... not even once, for anything, ever. I suspect many G1 Insight owners are in the same camp. If my assumption is correct, then I recommend using a USB-A connector for Pegasus firmware update process.

USB-C is certainly the future standard, but IMO USB-A is more appropriate for this application. It's not the end of the world either way; USB-C-to-A adapters are cheap and transparent above the PHY layer.

I didn't want to pollute @Mario's thread with an only tangential discussion. I am moving data between phone and laptop with USB C and my collection of devices now using USB C connectors for charging (from Macs to phones to flashlights) has given me box of USB C cables. I despised USB Micro, the most damage prone and unreliable mass-produced connector in the world. But USB C is working out.

Anyway, I have pretty much settled on RS-485 for data transfer in my car, given that even the worst case stub length is still going to let me exceed 500 kb/s. And this can be dealt with by including two pair in the cable to the device, to extend the bus to the device and back.

If you have built all the devices in your car, I have come to the conclusion that all the CAN benefits of a CRC and collision handling and packetizing is lost in only being able to send eight characters without some other strategy! BLE or Bluetooth SPP sounds cool, and above is an experiment in using BLE to use phones as a display. But it too is overly complex if you just want to move stuff around and can live with a sub $20 display, and then there is FCC certification...

And this week I received TTL to RS-485 half-duplex modules which appear (because I have not tested them) to automagically switch to transmit when the MCU sends it TTL data. This means that I can get away with four wires - power, ground, and single pair (two pair if I don't want it to be a stub) - to my devices. So I was on Digikey looking for cable and seeing how much it cost. And then realized that I had plenty of cable - connectorized - these cheap USB C cables.

So I wondered, are there USB C breakout boards? and of course there are, 5 for $8 if you want them tomorrow.

So I am pretty sure that the toys I'm building for the car are not going to use BLE like I thought or CAN like I thought but just the USB C physical connector for power, and the +/- USB A pair in the cable for balanced RS-485. And if don't want a stub, well, I could hack a cable to access the other pairs, but they are so cheap, why not just have a second breakout and connector on the device to run connect to the next device down the chain. Run everything at 5V, grab USB-C cables from the junk drawer, attached them to USB-C breakouts - DONE.

 

[*sean*]

Three more reasons I'm abandoning the Bluetooth implementation (other than RS-485 is easier): I have 20 bytes to work with per BLE message before I have to deal with fragmenting messages. It's dumb to write an app per sensor when the phone should get this info from a central controller. And displays are cheap enough if there is no central controller.

 

[Mario]

I have used RS-485 over ethernet cables before, it has a lot of advantages.
It's 100 ohm differential impedance, which is close to the ideal 120 ohm that RS-485 uses. You just terminate the ends with a 100 ohm resistor instead of 120 ohm. It uses slightly more power and has a slightly lower differential voltage, but modern drivers are good enough that it doesn't matter in practice. It's still in spec for the transceivers.
Ethernet cables are cheap and can be had in any length you need off the shelf.

I used one pair for power and one pair for ground (not power and ground in each pair, one pair only + and one pair only -. This will keep things from blowing up if you ever plugged actual ethernet into your system). One pair to transmit data and one pair to send data back.

This creates two RS-485 busses that supports any number of devices on it, where each device has two pass-through ethernet ports and you can just plug them all together. The master device sends data on the transmit bus, and all slaves read the message and decide if it's for them. One slave processes the command and sends data back on the receive bus. This requires a simple protocol and addressing scheme where each device has its own address and only one device transmits at a time (first the master on TX line, then one slave on RX line. Repeat over and over). This also requires having termination resistors on the master board and on the furthest slave board.

That's just one way to do the busses, you could also just use one pair and have it be half-duplex, and bring the bus back on the other pair so you only need termination on the master. But then you need a loopback on the last slave. But regardless, ethernet cables are a good way to go for this, IMO.
USB cables are 90 ohm differential impedance, so you'd need 90 ohm termination resistors. This is just a little too low, I think.