I think that #1 was merely not setting the little switch on the board to the correct direction. With the switch set into the left/up position, it boots correctly when power is applied.

This doesn't fix issue #2, still looking at that.

I think that #2 is caused by a thing where the chip resets itself when I send it too much serial port data all at once quickly. There is something in the documentation about how the chip can be reset with certain stuff related to serial port, but I'm not sure where the root of the issue lies yet. I continue to investigate.

Yeah there's something going on with the UART configuration of this Betz board which causes the chip to reset itself at random points during serial communications.

Whenever I issue a large series of commands to the thing all at once, it almost always resets itself, meaning that most of the commands don't get through at all.

On rare occasions it resets itself even if I type a fairly short innocuous command in the serial debug terminal, for example:

SET CONTROL BATTERY 0 0 0 0
WRAP THOR AI (6.2.0 build 1122)
Copyright (c) 2003-2017 Silicon Labs Inc.
READY.

I can't simply "delay" my commands to the thing because some of the stuff will need to be very fast responses.

None of this happened with the BlueGiga development board, I could send commands as fast as I wanted and there was no problem.

My first try was to disable the feature that puts it in and out of data mode via DTR signaling:
SET CONTROL ESCAPE - 00 0

That didn't help. Looking at other stuff.

Which serial port is this?
The USB port, or clipping onto the onboard pins?

If using the onboard pins, are those the same ones also being driven by the USB serial chip on the board?

I just had a look at the schematic, and yes, they are. You will need to cut the trace at JP4 to be able to use the WT32i serial port directly (non-USB).

Just run a very sharp knife between the two solder blobs there to cut the thin copper trace. This will deny power to the USB-serial chip.

Yep, that fixed it. NICE!

Note: This means that whenever we get one of these breakout boards we will have to make sure to flash it with the latest firmware BEFORE cutting that trace. And remember to reconnect the trace if we need to flash it again.

I was already on my way there, having noticed that the BlueGiga dev board schematic has special circuitry which disconnects its UART if no cable is plugged in to its USB port. You beat me to it!

I has also found this in the BlueGiga docs and was trying this but it didn't help: "The hardware flow control is enabled by default. HW flow control can be disabled in HW by connecting UART_NCTS to GND and leaving UART_NRTS floating."

I had also tried ENABLING the RTS/CTS lines to the UART by soldering their jumpers (which are disconnected by default). Also didn't help and actually prevented any serial communication from working at all.

Thank you so much! :-)

Perfect!

Oh, and nice job updating the Arduino code earlier on. I had a good look through it all and actually understood all of it.

Cheers!

ARRRRrrrrrgggghhhhhh!!!!!

Which of the four firmware files is the one I want for this?

[EDIT]
1122_aptxll <<<<--------- this one!
[/EDIT]

Cool! Now you can rewrite it properly instead of all hacky like I did! :-)

I've saved my latest code to that site just now, to pick up a couple more small tweaks I did.

I now have the new BetzTechnik board working equally as well as the original BlueGiga dev board. And my empeg is correctly outputting I2S and I'm getting digital music over the bluetooth. So all is well! Now I just have to print a new PCB board for the new design with the BetzTechnik board.

AWESOME!

That's been in the example code for a while, in the section that describes how to update the firmware. I admit, though, that the example code file is a little bit dense and a lot of the code comments in there should be turned into a proper instructions document which looks better and has things like a table of contents. Some time!

I don't know if there will ever be a newer firmware for this chip or not. :-)

Woo-Hoo!!!!!
Happy Daze is here again!

So.. a PCB that accepts the WT32i module directly, *without* the BetzTechnik board even being required?

Cheers

Hey, I resemble that remark!
Hacky is a Hijack specialty, out of necessity.

I'm now having visions of using your code as-is, compiling it with g++, after a few macros to fill in for the arduino-ish bits. Hoping those visions go away soon, as otherwise I'll have to confess them to my GP.

Cheers!

Would it be possible to solder some sort of switch or jumper pins between the two solder blobs, so that you can just switch the circuit off and on if you need to update the firmware?

They didn't space them enough to mount pins at that location, but one could solder two wires there and off to a switch somewhere.

But really, not a hardship. Just use the USB once to put the correct firmware onto it, and then cut the trace and plug it into the empeg. Done.

Yeah, totally possible, but a pain to assemble. I'm trying to design everything for quick and easy assembly, should this be something that others want to buy.

Mark's point about making my own PCB to accept a bare chip instead of the BetzTechnik breakout board is a good idea, maybe that is something Mark can do in his version. :-)

Hijack v522 is now available:

-- some IDE driver tweaks for better SSD compatibility.

-- BlueGigaEmpeg support as discussed in this thread, including new /proc/empeg_notify and serial port output for track "Source", track "Duration", and "Running order length".

-- in-car Hijack menu now includes the "Serial Port Assignment" entry.

Cool!

Does this version differ from the one I grabbed on Wednesday night (the one I got working with the new serial port parsing code)?

Wondering if I need to grab this new one or if doing so would make no functional difference.

Thanks!

Never mind, I'm grabbing it anyway just to be sure.

By the way, the http://empeg-hijack.sourceforge.net/ web page still says "2016-05-27" for the 522 version.

Hmmph. My upload script must have a date issue or something. No matter, just edited the date by hand now. Thanks!

Also, a reminder about my final wiring scheme for the I2S pins and how they relate to the tuner connector. I carefully disconnect three wires from the white connector inside of the empeg that is closest to the ethernet port on the empeg motherboard, and then solder them via jumpers to the IIS header as described in my source code, screenshot below.

Click to embiggen:

I was just now reading the hardware notes in the sketch, and it sounds like you are directly connecting the Arduino 5V TTL serial pins to the WT32i 3.3V CMOS serial pins.

If so, then you really should fix that. The datasheet for the WT32i clearly indicates that 5V is TOO MUCH INPUT VOLTAGE for any of its I/O pins.

So specifically, the TX line from the Arduino to the WT32i should get stepped down by 33%. The other line (TX from WT32i) is fine as-is.

Two resistors are needed for this: ideally 20K and 10K ohms, but lower K values will work so long as the 2:1 ratio is maintained (Eg. 10K and 5K). Or heck, even two resistors of the same value will work (Eg. 10K and 10K).

Connect the 10K to TX from the Arduino, connect the 20K to GND, and connect the other leads of each resistor to each other. The RX-input of the WT32i also gets connected to that same point (where the two resistors are tied together).

Click here to view the image full-size.

Cheers

I've now ordered an Arduino Mega clone board for getting started with this. That way I can work on car compatibility using Tony's exact code and feed back any changes required for the Harmon head unit in my new Subaru.

After that's all working, I'll work on eliminating the Arduino, and move the code to the empeg's main CPU.

Cheers

Interesting. That's exactly what I have been doing all along. Thanks so much for noticing this and raising the red flag. I am so grateful for your expertise on this.

Strangely, this part of it has been working perfectly all along. Of all the things I've had fail in the electronics, the serial connection between the Arduino and the WT32i chip was not ever one of those failures.

On the other hand, all the other stuff that failed could have been secondary effects from my mistake. I'll make the correction that you suggest right away.

I'm planning on ordering another sandwich board from Pad2Pad. It's the in-between board that mates the Arduino with the bluetooth dev/breakout board. I had one working for the big BlueGiga board and I'm currently refining one for the Betz board. Thanks for letting me know about this before I finalized it and placed the order with Pad2Pad.

When I get that board it printed, do you want one?

Also, please let me know if you notice any additional inconsistencies or weirdness in the hardware connection information in the code comments. I have been using that as a catch all place for my own notes and have been intending to rewrite it more clearly and/or draw up a proper schematic for this thing. It's possible that there might have been a transcription error or an omission in there somewhere.

I have a question about the voltage divider circuit you're suggesting.

You say that it isn't needed on the arduino RX pin, only on its TX pin. Is that because the voltage is truly directional for RX and TX like that (i.e., the voltage is always driven by the sender on that pin)?

In other words, tx from a 5v device is always 0v for either not transmitting or for bit 0, and then always +5v for bits? And then RX is always an input and never outputs any voltage?

I answered my own question about the 0v/5v thing (example here: https://www.sparkfun.com/tutorials/215 - the whole reason we need a Max232 is because the signaling is 0v/5v for the line-level and +13/-13 for the RS-232 level).

But does that mean the chip connected to the TX is always the one supplying the voltage? So for example if I accidentally connect a TX to a TX then it's two voltage suppliers competing?

Yes, and yes.

And having two sources of 5V logic trying to drive the same wire results in them driving each other.. and perhaps frying each other.

When they are both at 5V, no problem. When they are both at 0V, no problem, but when they are toggling bits (alternating 5V and 0V in some pattern), then there are many instances where one is 5V, the other is 0V, and so the 5V is driving current backwards into the 0V line. Fried chips! [EDIT: because they are drivers, they have very little resistance to current flow, which means when 5V gets connected to 0V in this way, near infinite current will flow (Ohm's Law), and something will suffer. Badly.]

TX lines are always "drivers", and RX lines here are always passive receivers. So in the case of the Arduino TX-out going to the WT32i RX-in, the Arduino will be toggling between approx 5V and 0V for its bits, exceeding the voltage limit on the WT32i RX pin. Thus the need for the voltage divider.

The other way around, from the WT32i TX-out to the Arduino RX-in, no problem. The most the WT32i will output might be around 3-3.3V, and the Arduino is built to tolerate up to 5V there without issue. The important thing here is that the "1" voltage has to meet the Arduino's minimum spec for a "1", and that is usually between 1.8V and 2.4V (minimum) for 5V logic. So no problem there either.

Cheers!

On a related note, I haven't yet checked the voltages on the breakout board when it is powered from +5V. I got slightly lost trying to grok their schematic to see what voltage it was actually supplying to the WT32i. No guarantee they got it right.

The bluetooth module wants 3.3V, but it wasn't clear to me if the breakout board was respecting that limit or not. I plan to power my own breakout board with 3.3V from the Arduino initially, and from the empeg itself eventually. This may require changing one of the "jumpers" on the breakout board. TBD.

Cheers

Okay, I just dug out the voltmeter, and measured 2.5V between VDD_IO and GND on the WT32i module itself, when supplied with 5V over the USB cable. On re-review of the schematic, this makes sense, as there is a honking 2.5V regulator onboard for this purpose.

So if one plans to supply the board that way (5V to the 5V pin, resulting in 2.5V at the VDD_IO pin), then the resistors for the serial port will need to be different than what I suggested above: just make them equal in value. So a pair of 10K resistors, or 15K resistors would be ideal. This would split the 5V logic levels in half, to 2.5V. Perfect.

The idea of a large K value here (as opposed to say, 1K-1K) is to prevent wasteful current draw (Ohm's Law), thereby saving power and keeping the Arduino and WT32i cool.

If powering the WT32i with 3.3V, then the 20K/10K pair is still correct.

Cheers