Honda Insight Forum banner
201 - 220 of 977 Posts

·
Linsight Designer
Joined
·
2,647 Posts
Discussion Starter · #202 · (Edited)
Nice video.

How much throttle were you applying? Tps reading?
Very close to no throttle; just enough to prevent the electric motor from driving the engine. The backlight stopped working in my OBDIIC&C a while back so I didn't think to turn a light on and read it... it's been working overtime with me on the H-line, too. The video is unpractical for any sustained period, as the IMA motor would overheat. I haven't installed temperature sensors near the motor yet*, but I will once I have a unified PCB.

*Customers won't need to install temperature sensors in the flywheel housing. I am doing this so I can see how hard Linsight is allowed to push the motor over various time intervals... it'll essentially integrate |power| over the last n seconds and if the area under the curve exceeds some limit, then power is throttled back. As always, a power user can set higher limits, but the stock limit will be exceedingly cautious. None of this concept exists right now, but it's supported and I'll get it coded once I have a working PCB.

...

In regards to the PCB, I'm still struggling through routing all the functionality out of my processors:
-The time-critical processor that controls the PWM sine drive has 0 pins left. Fortunately, nothing else needs to connect.
-The (100 pin) main processor has 9 free pins, but they're mostly static (i.e. useless) software-timed I/O. I spent two solid days routing out the hardware-timed functionality (PWM/UARTs/Counters/ISRs/etc). I could have upgraded to an equivalent processor with 144 pins (and no additional functionality), but I'm worried I'll run out of PCB real estate. I'm 99.9% certain I've got the 100 pin package figured out and am just hammering out a few final inconsistencies. FYI: Even though the main processor's manual is 1315 pages long, it's still lacking documentation.
 

·
Registered
Joined
·
167 Posts
Just saw the video; it's really cool. Seems like we're going to have a problem I don't mind having, which is that now we might need to switch to metric to figure out just how good our mileage really is :)
 

·
Linsight Designer
Joined
·
2,647 Posts
Discussion Starter · #204 ·
Seems like we're going to have a problem I don't mind having, which is that now we might need to switch to metric to figure out just how good our mileage really is :)
Maybe that'll be the tipping point for the US to metricize? ;)
 

·
Premium Member
Joined
·
3,641 Posts

·
Linsight Designer
Joined
·
2,647 Posts
Discussion Starter · #206 · (Edited)
Hey Peter and Chris,
How do y'all's devices drive TDX/RDX (a.k.a. "H-Line")?
Now that OBDIIC&C, Pegasus, and Linsight can drive this line simultaneously, I want to make sure we're all using an open drain (collector) or equivalent, with a pullup. Don't want to blow up a transmitter if two of us decide to talk simultaneously.

Unless y'all have feedback otherwise, here's how I'm planning on driving TDX/RDX:
Text Green Font Line Technology

edit: disregard the fact that I can't spell 'echoes' properly.
 

·
Premium Member
Southern California
Joined
·
896 Posts
I am using open collector:



The "out" drivers are for the OBD-II device that you'll be able to plug into Pegasus (so you can use Pegasus and, say, OBDIIC&C at the same time).

I didn't include pullup resistors on the lines coming from the car because they already have pullups, correct?

Edit: Just to be clear - if OBDIIC&C is plugged into Pegasus, it does not talk to the car directly. Pegasus is the only device talking to the car. Pegasus gets PID requests from OBDIIC&C and then relays them to the car, waits for a response, and sends the data back to OBDIIC&C. There should be no conflicts, this way.
 

·
Linsight Designer
Joined
·
2,647 Posts
Discussion Starter · #208 · (Edited)
I am using open collector:
I didn't include pullup resistors on the lines coming from the car because they already have pullups, correct?
Correct (on your end). The pullup is in the MCM (3.3k). Your circuit and mine are compatible. Note that your circuit inverts Pegasus' TX output, so you'll need to tristate your TX (to let the resistor pull TX down) instead of idling high. I'd use a much lower resistor (maybe 10k vs 100k) to ensure you don't break the bus (i.e. pull it low) if Pegasus malfunctions, etc. FYI: I'm assuming your uC has pullups.

The "out" drivers are for the OBD-II device that you'll be able to plug into Pegasus (so you can use Pegasus and, say, OBDIIC&C at the same time). If OBDIIC&C is plugged into Pegasus, it does not talk to the car directly. Pegasus is the only device talking to the car.
Linsight will talk to the car, too, via the H-line, as the K-line doesn't route to the MCM. Thus, some device - either OBDIIC&C, Pegasus, or my own OBDII plug - must translate the H-line requests to the K-line, then back. I'm considering plugging my user controls into the H-line, too, but I also have USB OTG support (for USB joysticks, etc). I should be able to support nearly any device ;).

Pegasus gets PID requests from OBDIIC&C and then relays them to the car, waits for a response, and sends the data back to OBDIIC&C. There should be no conflicts, this way.
Wish I could piggyback on that circuit, too... sounds like I'll only contend with EITHER Pegasus OR OBDIIC&C. Works for me ;).
 

·
Premium Member
Southern California
Joined
·
896 Posts
How exactly do you detect collisions? Do you just read in the byte you are sending to make sure it's the same thing? (If another device pulled the line low in that time, the byte would read back differently.)

You are correct that my TX outputs are inverted, but I'm not sure how it relates to the pull down I have.
That 100k pull down is just to make sure that transistor stays turned off while the microcontroller is booting up. After that, the micro is always driving the base either high or low, which would ground the H-Line or tristate it, respectively.
The inverted logic is not an issue as I can invert my UART's output with a simple register setting.

As for the H-Line to K-Line requests, you could still talk to Pegasus through the RS-485 line. But then you're outta luck if the user doesn't have Pegasus, so probably not a good solution.
I'm not sure how you're envisioning your H-Line to K-Line translator working with either OBDIIC&C or Pegasus plugged in. Would it do similar to Pegasus and receive all requests and mediate for the devices?

In addition, with so many devices, the low communication speed becomes a real issue. OBDIIC&C uses the K and H lines for about 50% of the time with only 4 requests/sec on each, and Pegasus would probably use the rest of that. How much data are you thinking of requesting?
 

·
Linsight Designer
Joined
·
2,647 Posts
Discussion Starter · #210 · (Edited)
How exactly do you detect collisions? Do you just read in the byte you are sending to make sure it's the same thing? (If another device pulled the line low in that time, the byte would read back differently.)
Correct. I read the byte I just wrote and if it's different, then there's a collision.

You are correct that my TX outputs are inverted, but I'm not sure how it relates to the pull down I have.
That 100k pull down is just to make sure that transistor stays turned off while the microcontroller is booting up. After that, the micro is always driving the base either high or low, which would ground the H-Line or tristate it, respectively.
The inverted logic is not an issue as I can invert my UART's output with a simple register setting.
I was just pointing out that 100k is pretty large; many microcontroller IOs source [email protected]~20:100uA during powerup, so I like to pull critical signals with at most 10k, thus preventing errant driving. A serial bus isn't critical, so 100k works. Just a random rambling ;).

As for the H-Line to K-Line requests, you could still talk to Pegasus through the RS-485 line. But then you're outta luck if the user doesn't have Pegasus, so probably not a good solution.
I'm not sure how you're envisioning your H-Line to K-Line translator working with either OBDIIC&C or Pegasus plugged in. Would it do similar to Pegasus and receive all requests and mediate for the devices?
There are three use cases:
1) If OBDIIC&C is installed, but not Pegasus, OBDIIC&C sends my data to K-line via H-line. Linsight doesn't connect to K-line.

2a) If Pegasus is installed, Pegasus sends my data to K-line via H-line, regardless of whether or not OBDIIC&C is plugged into Pegasus' OBDII port; this changed today after you mentioned you're arbiting OBDIIC&C. Linsight doesn't connect to K-line.

2b) As 2a, but Linsight sends "K-line requests" via METSCI bus. Pegasus sends K-Line data back to Linsight either via METSCI bus (if termination issues we discussed previously allow it*) OR via H-line.

3) If neither Pegasus nor OBDIIC&C are installed, Linsight has an optional OBDII connector that has a ATtiny that will drive my data to K-line via H-line. Linsight still doesn't connect to K-line (but my OBDII connector with no wires does).

...

I like option 2b. It allows Linsight to automatically figure out how to get K-line data: "Is Pegasus responding to my requests?" If not, get data via OBDIIC&C (or my OBDII, which uses the same protocol).

One other option is a spare UART I've routed out to screw terminals with VCC/GND. OBDIIC&C could plug in there if Peter's device can handle it. In this configuration, Pegasus could send data to Linsight via H-Line, and Linsight could send data to Pegasus with METSCI, making both buses transmit in the same direction 100% of the time. Linsight would relay OBDIIC&C's data full duplex via the UART.

In addition, with so many devices, the low communication speed becomes a real issue. OBDIIC&C uses the K and H lines for about 50% of the time with only 4 requests/sec on each, and Pegasus would probably use the rest of that. How much data are you thinking of requesting?
I'd like to request at least:
-throttle position (pretty regularly)
-lean burn parameters (pretty regularly)
-engine & ambient temperature (once per minute)

I'm sure we three can divide bandwidth as required. Poor little H-line... Honda engineering had no idea ;).

...

*I did some more research and decided to add a 120 Ohm resistor on my end as well. The specification requires line drivers to drive into 50 Ohms, so I'm now disregarding the LT1487's minimum guaranteed current specification.
 

·
Linsight Designer
Joined
·
2,647 Posts
Discussion Starter · #211 · (Edited)
The Linsight schematic is finished enough to finish layout. It's only two pages, but should have been more... I don't like KiCAD's interpage connector interface: buses aren't allowed through, so you have to break them all out, then wrap them all back up on the other side. Thus the BMS (SPI) is the only thing on page 2.

Without further ado, I present the RevA Linsight schematic:
View attachment Linsight Schematic 2016JAN19.pdf

I will accept any and all feedback up until the moment I order the PCB (in the next few days). There are no stupid questions. Ask me "why?" on anything... I don't mind looking anything over again.

FYI: Processors are AT32UC3C1512C (nine free pins left) & ATmega64M1 (zero free pins left).
 

·
Registered
Joined
·
4,009 Posts
Did you solve the discontinued processor issue?
 

·
Linsight Designer
Joined
·
2,647 Posts
Discussion Starter · #214 ·
2016JAN20 update:
Layout is going well. I can already tell everything is going to fit!
Electronic engineering Circuit component Electronics Microcontroller Technology

I'll probably finish the layout tomorrow evening and then review it Thursday morning. Anyone reviewing my schematic should have feedback in by Thursday 12 noon CT.
 

·
Premium Member
Southern California
Joined
·
896 Posts
Looking good so far! I like cramming complicated layouts onto 2-layer boards. It's more fun than just switching to four layers (as long as you don't need good impedance control). :)

Got any art or logos you're planning to put on there?
Could just draw an Insight or something like on (shameless plug) a different board I made:
 

·
Registered
Joined
·
4,009 Posts

·
Linsight Designer
Joined
·
2,647 Posts
Discussion Starter · #218 ·
Got the PCB ordered with 28 minutes to spare before the Chinese New Year cutoff... that was close:
Electronics Electronic engineering Technology Electronic device Circuit component

Top (signal):
Electronic engineering Electronics Microcontroller Circuit component Hardware programmer

Layer 2 (power):
Can you find the secret message that'll be hiding underneath the connector on layer 2? :)
Yellow Font Parallel

Layer 3 (ground):
Looks the same as layer 2; IC's 4 picture limit requires your creativity. Squint hard while looking at layer 2.

Layer 4 (signal):
Electronics Electronic engineering Technology Electronic device Circuit component

I was in a fine hurry and review the layout as much as I'd wanted to, but it'll be better to have something instead of nothing for a few weeks. Hopefully I don't blow my "shipping Rev A's" streak!

No fancy graphics... I hardly had any room left anyways and didn't want to pay for a back side silkscreen; also, I ran out of time. Maybe I'll add a fancy graphic on the production order.
 

·
Premium Member
Joined
·
136 Posts
Way to go mudder! I know myself and a lot of fellow Insight enthusiasts owe you a great debt for this. For those of use who truly love these little cars, this really is a dream come true and I want to thank you for the time you have put in to make it happen. Your talent is truly impressive.

-Steve
 

·
Linsight Designer
Joined
·
2,647 Posts
Discussion Starter · #220 · (Edited)
Way to go mudder! I know myself and a lot of fellow Insight enthusiasts owe you a great dept. for this. For those of use who truly love these little cars, this really is a dream come true and I want to thank you for the time you have put in to make it happen. Your talent is truly impressive.

-Steve
Thanks, Steve! Ordering the PCB is a huge milestone, but there's still a lot more work to do on the programming side. Assuming the RevA works well enough to prototype with, I've probably got a couple hundred more hours of work left before I send prototypes to interested customers (let me know), then a couple hundred more before I'd call the product 'finished'. Fortunately I tend to work 100+ hour weeks, so it shouldn't take too long.

Alas, I won't get the actual PCB for a week (that's actually very fast, and was also $$$). While I'm waiting for the PCB, I'll order parts to assemble the boards with (I'm building 5 prototypes). I'll also start working on the firmware test code: I'm writing small programs to test each sub-system in what's called "hardware-in-the-loop" (HIL) testing: since I know pretty much everything about the OEM signals, I can simulate the entire insight with a computer, and then I can see how Linsight responds to various inputs. That way I'm not just holding my finger up to the wind; I'll know very quickly whether or not the hardware is functionally correct.

Then comes the hard part: cramming all functionality onto both processors at the same time. This is almost certainly going to result in head-banging on walls/tables/floor, but eventually everything will pass my HIL testing. Then - and only then - will I put Linsight into my personal insight and cross my fingers I decoded all the signals properly. From there, the software should only need minor tweaking to account for any signals I missed, then a little PID tuning and finally I'll integrate Pegasus' com bus.

Also, I haven't started my joystick solution yet, so for now the early adopters will need Peter's OBDIIC&C AND the joystick he sells that plugs into said OBDIIC&C. I've probably run out of time to juggle a joystick design, too. We'll see how much energy I have tomorrow; maybe I can knock out that design in a day or so.

...

After March 14th I'll only be able to write software, as I'll be on the road until Thanksgiving 2016. Thus, I won't have access to any engineering tools or my PCB assembly line. That gives me 7 weeks to finish the hardware and build enough units to distribute throughout 2016.

Once I'm on the road, I won't have access to my insight, but I'll still program. Hopefully a brave insighter will run my (untested) code updates and report back. Otherwise, there won't be any tested software updates after March 14.
 
201 - 220 of 977 Posts
Top