#369848 - 28/11/2017 11:38
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Desoldered the codec chip and all its corresponding capacitors.
Heating problem went away and board still works, but no I2S audio.
Made extra sure about the I2S connections by jumpering them directly to the correct BlueGiga chip pins. Still no I2S audio.
Did some continuity testing, and the SCK pin on the BlueGiga chip has continuity with the 3v rail. Maybe that's the root of it.
I'm back down to analog audio now.
|
|
Top
|
|
|
|
|
#369850 - 28/11/2017 14:49
Re: BlueGigaEmpeg
[Re: mlord]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
I do seem to recall having to fix the Arduino library here for one of my projects: it had WAY too small of a serial RX buffer for my needs. Increased the buffer size, and problems went away.
Ahh.. here's the file:
arduino-x.x.x/hardware/arduino/avr/cores/arduino/USBAPI.h
Look for "#define SERIAL_BUFFER_SIZE" and make it bigger.
I thought I'd try this, even though I had convinced myself it wasn't the root of the issue, I'm having trouble locating the root of the issue so I'm going back over my previous assumptions and I'd like to try this. My problem is that I can't find the file in question. I'm doing the development on Mac OS X and the file just isn't showing up anywhere that I look for it. Searching for this information on Google isn't giving me any valid answers, unfortunately. Any ideas?
|
|
Top
|
|
|
|
|
#369851 - 28/11/2017 15:05
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
I found the file - Macs have something that looks like a single application file (in this case "Arduino") but it's actually like a zip file. The USBAPI.h was in there. I am not 100 percent certain that I edited it correctly or that the compiler will "take" the file or not, but I tried it. I changed it to 256 but it didn't fix the issue. 
|
|
Top
|
|
|
|
|
#369852 - 28/11/2017 17:46
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
I think the best place to connect external 3.3V power to the BT-dev board would be at the (white, 2-pin) battery connector (or to the "Battery Current" jumper). That input will accept up to 4.4V, and it gets internally regulated to what the various parts of the dev board want. Connecting it directly to the 3.3V (OUTPUT) on the top-left header isn't ideal, and could be why parts of the board want to overheat. Now, why the external USB power wasn't working: this should just be due to the 5V-to-3.3V conversion chips perhaps having failed. There are two chips in series for this: U14, and then U1 (labelled photo attached).  U14 (on the right) converts the 5V from USB down to 3.6V ("battery level"). U1 (on the left) converts the 3.6V from U14 down to 3.3V ("logic level"). You can check for correct operation of each of those with a voltmeter. Power the board from the USB connector (or possibly the UART connector, but I'm using the USB connector here). The top left pin of each chip is its output. Measure voltages using either of the USB shells as GND. The chip on the left (U1) should be outputting 3.3V, and the chip on the right (U14) should show 3.6V. If either chip doesn't show the correct output, then check the input to each chip, on the bottom left pin ( magenta dots in the photo). So, check those and report back.
|
|
Top
|
|
|
|
|
#369853 - 28/11/2017 17:52
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
Did some continuity testing, and the SCK pin on the BlueGiga chip has continuity with the 3v rail. Maybe that's the root of it. From reading the datasheet, it appears that SCK (and SWS) are bidirectional. The Wt32i can be programmed to have those as inputs (what we need), or as outputs. If the latter, then you'll see 3.3V on them (bad).
|
|
Top
|
|
|
|
|
#369854 - 28/11/2017 17:55
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
I like the look of that. Cheap-ish at only USD$10+shipping (without WT32i). And it takes care of converting the pin spacings to something more usable for us. Ordered one!If you look at the schematic for it, it shows what extra circuitry is needed to run a standalone wt32i: not much, just a 5V to 3.3V power supply, and it also provides a USB-UART for easy programming. That, with a WT32i module on it, looks darned near perfect for our needs when using I2S.
|
|
Top
|
|
|
|
|
#369855 - 28/11/2017 18:23
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
I am not 100 percent certain that I edited it correctly or that the compiler will "take" the file or not, but I tried it. I changed it to 256 but it didn't fix the issue. There were two lines with that setting in mine here, with an #ifdef deciding which one to use. You can test whether or not your mod gets picked up by inserting a #error line there for testing. Eg. #error "it works"
|
|
Top
|
|
|
|
|
#369857 - 28/11/2017 21:46
Re: BlueGigaEmpeg
[Re: mlord]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
There were two lines with that setting in mine here, with an #ifdef deciding which one to use.You can test whether or not your mod gets picked up by inserting a #error line there for testing. Eg. #error "it works" Mark, you are brilliant, thank you. My change isn't getting picked up. I inserted the #error "it works" , both with and without the quotes (the file has an example of it without the quotes right below there) and tried putting it both before and after some of the #if statements surrounding the SERIAL_BUFFER_SIZE stuff in that section of the code (including placing it before the #ifndef SERIAL_BUFFER_SIZE statement so it should definitely have been hit). The compilation step never blows up with an error message, either when using the installed local Arduino compiler or their online compiler. So if my issue really is a serial buffer size issue, then this change isn't helping because it's never hitting the change. That's so awesome that you suggested putting an error into the compilation to see if it even hits the code. Super helpful! I've been googling around trying to find the correct way to do this, and all the answers say either "make sure your code doesn't ever let the buffer fill up" or they suggest changing the exact same line that you already suggested changing. If the serial buffer does turn out to be the root of the issue, then I would want to rearchitect the code to fix the issue, but before I do that I need to know if that's even the issue at all, so I want to try to get this buffer size experiment working. I'll keep poking at it. By the way, the file in question was located in this place on the Mac: Macintosh HD -> /Applications/Arduino (which, once you're inside it, gets listed as "Arduino.app" in the directory tree) (then you have to open the contents of the "Arduino" App, then) Contents/Java/hardware/arduino/avr/cores/arduino/USBAPI.h When compiling I have tried both the "AVR ISP" programmer option and the "AVRISP Mk II" programmer option, and the compiler output says that at least it's hitting the right folder, though I don't see that particular file in the list:
/Applications/Arduino.app/Contents/Java/arduino-builder -dump-prefs -logger=machine -hardware /Applications/Arduino.app/Contents/Java/hardware -tools /Applications/Arduino.app/Contents/Java/tools-builder -tools /Applications/Arduino.app/Contents/Java/hardware/tools/avr -built-in-libraries /Applications/Arduino.app/Contents/Java/libraries -libraries /Users/tonyfabris/Documents/Arduino/libraries -fqbn=arduino:avr:mega:cpu=atmega2560 -vid-pid=0X2341_0X0042 -ide-version=10805 -build-path /var/folders/6w/0th2m9n50q5dlyh_93g3_lw40000gn/T/arduino_build_771320 -warnings=none -build-cache /var/folders/6w/0th2m9n50q5dlyh_93g3_lw40000gn/T/arduino_cache_72365 -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.avr-gcc.path=/Applications/Arduino.app/Contents/Java/hardware/tools/avr -prefs=runtime.tools.arduinoOTA.path=/Applications/Arduino.app/Contents/Java/hardware/tools/avr -prefs=runtime.tools.avrdude.path=/Applications/Arduino.app/Contents/Java/hardware/tools/avr -verbose /Users/tonyfabris/Documents/Windows Laptop/My Documents/Empeg related documents/BlueGigaEmpeg/BlueGigaEmpeg.ino
/Applications/Arduino.app/Contents/Java/arduino-builder -compile -logger=machine -hardware /Applications/Arduino.app/Contents/Java/hardware -tools /Applications/Arduino.app/Contents/Java/tools-builder -tools /Applications/Arduino.app/Contents/Java/hardware/tools/avr -built-in-libraries /Applications/Arduino.app/Contents/Java/libraries -libraries /Users/tonyfabris/Documents/Arduino/libraries -fqbn=arduino:avr:mega:cpu=atmega2560 -vid-pid=0X2341_0X0042 -ide-version=10805 -build-path /var/folders/6w/0th2m9n50q5dlyh_93g3_lw40000gn/T/arduino_build_771320 -warnings=none -build-cache /var/folders/6w/0th2m9n50q5dlyh_93g3_lw40000gn/T/arduino_cache_72365 -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.avr-gcc.path=/Applications/Arduino.app/Contents/Java/hardware/tools/avr -prefs=runtime.tools.arduinoOTA.path=/Applications/Arduino.app/Contents/Java/hardware/tools/avr -prefs=runtime.tools.avrdude.path=/Applications/Arduino.app/Contents/Java/hardware/tools/avr -verbose /Users/tonyfabris/Documents/Windows Laptop/My Documents/Empeg related documents/BlueGigaEmpeg/BlueGigaEmpeg.ino
Using board 'mega' from platform in folder: /Applications/Arduino.app/Contents/Java/hardware/arduino/avr
Using core 'arduino' from platform in folder: /Applications/Arduino.app/Contents/Java/hardware/arduino/avr
Detecting libraries used...
"/Applications/Arduino.app/Contents/Java/hardware/tools/avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -flto -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10805 -DARDUINO_AVR_MEGA2560 -DARDUINO_ARCH_AVR "-I/Applications/Arduino.app/Contents/Java/hardware/arduino/avr/cores/arduino" "-I/Applications/Arduino.app/Contents/Java/hardware/arduino/avr/variants/mega" "/var/folders/6w/0th2m9n50q5dlyh_93g3_lw40000gn/T/arduino_build_771320/sketch/BlueGigaEmpeg.ino.cpp" -o "/dev/null"
Generating function prototypes...
"/Applications/Arduino.app/Contents/Java/hardware/tools/avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -flto -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10805 -DARDUINO_AVR_MEGA2560 -DARDUINO_ARCH_AVR "-I/Applications/Arduino.app/Contents/Java/hardware/arduino/avr/cores/arduino" "-I/Applications/Arduino.app/Contents/Java/hardware/arduino/avr/variants/mega" "/var/folders/6w/0th2m9n50q5dlyh_93g3_lw40000gn/T/arduino_build_771320/sketch/BlueGigaEmpeg.ino.cpp" -o "/var/folders/6w/0th2m9n50q5dlyh_93g3_lw40000gn/T/arduino_build_771320/preproc/ctags_target_for_gcc_minus_e.cpp"
"/Applications/Arduino.app/Contents/Java/tools-builder/ctags/5.8-arduino11/ctags" -u --language-force=c++ -f - --c++-kinds=svpf --fields=KSTtzns --line-directives "/var/folders/6w/0th2m9n50q5dlyh_93g3_lw40000gn/T/arduino_build_771320/preproc/ctags_target_for_gcc_minus_e.cpp"
Compiling sketch...
"/Applications/Arduino.app/Contents/Java/hardware/tools/avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -flto -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10805 -DARDUINO_AVR_MEGA2560 -DARDUINO_ARCH_AVR "-I/Applications/Arduino.app/Contents/Java/hardware/arduino/avr/cores/arduino" "-I/Applications/Arduino.app/Contents/Java/hardware/arduino/avr/variants/mega" "/var/folders/6w/0th2m9n50q5dlyh_93g3_lw40000gn/T/arduino_build_771320/sketch/BlueGigaEmpeg.ino.cpp" -o "/var/folders/6w/0th2m9n50q5dlyh_93g3_lw40000gn/T/arduino_build_771320/sketch/BlueGigaEmpeg.ino.cpp.o"
Compiling libraries...
Compiling core...
Using precompiled core
Linking everything together...
"/Applications/Arduino.app/Contents/Java/hardware/tools/avr/bin/avr-gcc" -w -Os -g -flto -fuse-linker-plugin -Wl,--gc-sections,--relax -mmcu=atmega2560 -o "/var/folders/6w/0th2m9n50q5dlyh_93g3_lw40000gn/T/arduino_build_771320/BlueGigaEmpeg.ino.elf" "/var/folders/6w/0th2m9n50q5dlyh_93g3_lw40000gn/T/arduino_build_771320/sketch/BlueGigaEmpeg.ino.cpp.o" "/var/folders/6w/0th2m9n50q5dlyh_93g3_lw40000gn/T/arduino_build_771320/../arduino_cache_72365/core/core_arduino_avr_mega_cpu_atmega2560_51f02b7210b938436b779d1c032618e1.a" "-L/var/folders/6w/0th2m9n50q5dlyh_93g3_lw40000gn/T/arduino_build_771320" -lm
"/Applications/Arduino.app/Contents/Java/hardware/tools/avr/bin/avr-objcopy" -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0 "/var/folders/6w/0th2m9n50q5dlyh_93g3_lw40000gn/T/arduino_build_771320/BlueGigaEmpeg.ino.elf" "/var/folders/6w/0th2m9n50q5dlyh_93g3_lw40000gn/T/arduino_build_771320/BlueGigaEmpeg.ino.eep"
"/Applications/Arduino.app/Contents/Java/hardware/tools/avr/bin/avr-objcopy" -O ihex -R .eeprom "/var/folders/6w/0th2m9n50q5dlyh_93g3_lw40000gn/T/arduino_build_771320/BlueGigaEmpeg.ino.elf" "/var/folders/6w/0th2m9n50q5dlyh_93g3_lw40000gn/T/arduino_build_771320/BlueGigaEmpeg.ino.hex"
Sketch uses 19780 bytes (7%) of program storage space. Maximum is 253952 bytes.
Global variables use 2288 bytes (27%) of dynamic memory, leaving 5904 bytes for local variables. Maximum is 8192 bytes.
|
|
Top
|
|
|
|
|
#369858 - 28/11/2017 21:50
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Aha, it's merely a different file these days. The file you listed was from an old version. What we're looking for here is this file:
/Applications/Arduino.app/Contents/Java/hardware/arduino/avr/cores/arduino/HardwareSerial.h
That one hits the #error statement if I insert it, and also, it has separate RX and TX buffers.
Now we're talkin'.
|
|
Top
|
|
|
|
|
#369859 - 28/11/2017 22:08
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
|
|
Top
|
|
|
|
|
#369860 - 28/11/2017 22:08
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
And of course you were right. The bug goes away if I increase the serial buffer size. I feel terrible for rejecting your suggestion when you first made it.
I have to really rethink some things if I want to work around this issue, or, I could just depend on a bigger buffer. Hm.
|
|
Top
|
|
|
|
|
#369861 - 28/11/2017 22:13
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
My apologies for not specifying the correct file first time around.. I was looking at an older version of the Arduino stuff. Of course in the latest (which I also have and use) it is in the file you found.  The problem you face, is that the empeg bursts a ton of stuff rather quickly on track change. The buffer has to be big enough to hold all of that, or you have to be polling insanely too often. Bigger buffer is probably best, if you can spare the RAM. This will be a non-issue for me when I do it all internal to the empeg.
|
|
Top
|
|
|
|
|
#369862 - 28/11/2017 22:58
Re: BlueGigaEmpeg
[Re: mlord]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Bigger buffer is probably best, if you can spare the RAM. This will be a non-issue for me when I do it all internal to the empeg. Agreed. I can easily spare the RAM, but I'm trying to make this thing easy for third parties to put together themselves. Editing the Arduino compiler header files (and having to maintain that after Arduino compiler upgrades too) is a pain that I don't want to have to put anyone else through. But at the moment it's all I've got, for the reasons you cited. I wish I could just put "#define SERIAL_RX_BUFFER_SIZE 256" into my own code and be done with it, but of course that doesn't work. I could look and see if rearchitecting my code to use "serialEvent()" works, i.e., if it still calls that routine even if I'm deep inside another routine. In other words, make it truly event-driven instead of polling. I could constantly build up and regularly drain a stack of completed string lines from the Empeg serial port. That might be possible if that function works the way I think it should. In the meantime, I'm going to put a pre-check step into the Arduino sketch to print a warning message if the buffer size isn't big enough. And then I will move on to the power supply debugging you suggested earlier - Thanks again so much for that too, that is super helpful.
|
|
Top
|
|
|
|
|
#369863 - 29/11/2017 00:05
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Updated: https://create.arduino.cc/editor/tfabris/4c5eea9a-1462-45d7-908d-81a5bb6b0d90/previewTrack titles are much more reliable now. I fixed multiple bugs that would cause the track titles to sometimes not be parsed properly. Some of those bugs were new String/memory bugs that I induced when I made attempts to work around what I had incorrectly thought were String/memory bugs in the first place. There is also now the check routine in there to confirm at program startup that the string buffer size is big enough, and will print an error on the serial port if it isn't big enough. Considering whether or not to do something like halt the program and make the LED blink if the string buffer isn't big enough, but I haven't gone that far since the worst thing that could happen is the track titles don't always work.
|
|
Top
|
|
|
|
|
#369864 - 29/11/2017 00:12
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
Yes. That's a weakness in the Arduino library. The buffersize should be a parameter to each instantiation of a Serial object, rather than a hardcoded value that is applied to each and every serial port. Eg. Right now, if you change that define to 128, this means that all THREE of your serial ports are going to get the same large buffer, wasting a fair bit of precious RAM (on some chips anyway). But for now, if you can spare 3X whatever the buffer size, then just go with that. With the smaller WT32i breakout board you found (mine will be here later in the week), I suspect that board will be the one that anyone else here might choose to use. And it is a natural for placement inside the empeg. In which case, the eventual port of the Arduino sketch to native-empeg might end up being what is wanted. And it will have no such buffer issues, not least because Hijack already captures the notify strings and maintains the latest of each in /proc/empeg_notify for app use. So probably not worth fussing further over for now, at least. Heck, the Arduino library might even get fixed by the time you need a "simpler" solution. Or you could clone the serial library and distribute a fixed version for installation by others. Or just provide a pre-compiled binary of the sketch. Etc..
|
|
Top
|
|
|
|
|
#369865 - 29/11/2017 00:18
Re: BlueGigaEmpeg
[Re: mlord]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
U14 (on the right) converts the 5V from USB down to 3.6V ("battery level").
U1 (on the left) converts the 3.6V from U14 down to 3.3V ("logic level").
So, check those and report back. U14 on the right: 3.54v output on upper left output pin, source voltage on lower left pin: 4.39v U8 on the left: 3.28v output on upper left output pin, source voltage on lower left pin: 3.54v Additional voltages from the current jumpers in the middle of the board: 3.29v VDD_IO CURRENT 3.54v VDD_BAT CURRENT 1.15v VDD_CHG CURRENT (battery switch is off and no battery is installed) 0.00v BATTERY CURRENT (battery switch is off and no battery is installed) 4.39v USB CURRENT Something I haven't tried yet... Now that I've removed that TI codec chip, I'm going to see if powering it on its 5v VBUS pin works again.
|
|
Top
|
|
|
|
|
#369866 - 29/11/2017 00:27
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
Does it work when powering from USB?
Looks like it ought to.
|
|
Top
|
|
|
|
|
#369867 - 29/11/2017 00:36
Re: BlueGigaEmpeg
[Re: mlord]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Indeed it works just fine now, powering from either USB or from my board assembly with the tuner connector, using the 5v "Vbus" pin to power it like I was doing before the malfunction. And now, with that TI codec chip removed, nothing is getting hot any more. I still don't have I2S any more and I have to fall back to analog, though. Which works, but I really miss the cleaner sound that the I2S connection gave me.
I wish I knew which component was the failed one and whether or not I caused it.
I have high hopes for that other breakout board. I ordered one too. Once I get that smaller breakout board, what's your recommendation for which pin to power it from?
|
|
Top
|
|
|
|
|
#369868 - 29/11/2017 00:46
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
I have high hopes for that other breakout board. I ordered one too. Once I get that smaller breakout board, what's your recommendation for which pin to power it from? There's a contact hole/pin labelled "5V" on a corner of the board at the same end as the USB connector. The schematic shows that pin being connected directly to the 5V contact from the USB mini connector, so that's the one to use. Cheers
|
|
Top
|
|
|
|
|
#369869 - 29/11/2017 01:37
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
I wish I knew which component was the failed one and whether or not I caused it. I am wondering about that external I2S codec chip. If the Wt32i firmware isn't careful enough, or if perhaps the settings being used result in it enabling its outputs, then that chip could be driving voltage onto the I2S pins. Fighting the empeg voltages. Uh oh. That could result in a very hot chip, a fried chip, or perhaps fried I2S outputs on the empeg too. I think I'll just cut the I2S traces to/from that chip on mine before hooking them up to an empeg. Or do what you did and just get rid of the darned thing. Kinda surprising the dev board lacks jumpers to disable/bypass the chip.
|
|
Top
|
|
|
|
|
#369871 - 29/11/2017 16:05
Re: BlueGigaEmpeg
[Re: mlord]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Hypothetical question.
Let's say someone had previously modified the interior of their empeg according to my older wiring scheme of:
- Pink "Tuner Level" wire connected to "IISD1" pin
- Brown "TX" wire connected to "IISW" pin
- Red "RX" wire connected to "IISC" pin
Now let's say that person happened to have a home dock on their desk, one they'd made themselves out of an extra sled several years ago. And let's say that, hypothetically, behind their desk, they had hooked up an actual tuner module there to that home dock, one they hadn't made use of in years and had forgotten was there.
If, hypothetically, that person then docked their empeg into that dock to use emplode to modify some playlists, what might happen to the I2S/DSP circuits of that empeg in that case? And then later, if that same empeg was then reconnected to the BlueGiga dev board after that, what might happen to that dev board?
Asking for a friend.
|
|
Top
|
|
|
|
|
#369877 - 29/11/2017 23:08
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 08/07/1999
Posts: 5546
Loc: Ajijic, Mexico
|
Then she says, "you're not putting the paper into the printer upside-down, are you?" tanstaafl.
_________________________
"There Ain't No Such Thing As A Free Lunch"
|
|
Top
|
|
|
|
|
#369879 - 29/11/2017 23:24
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
If, hypothetically, that person then docked their empeg into that dock to use emplode to modify some playlists, what might happen to the I2S/DSP circuits of that empeg in that case? Outputs fighting outputs. Something's gonna get fried. I'll see if I can figure out a way for you to test whether or not the empeg I2S is still working or not -- an oscilloscope or logic analyzer would be ideal, but perhaps other means might work here. EDIT: Okay, volt meter on pins 1,2,4,5 of the I2S header. On my empeg, they all average out to about 2.4V while playing Pink Floyd. If your empeg board is no longer outputting I2S, then it's strictly limited to the DSP chip -- replace that, and all would be good again. But more practically speaking, if you don't have a spare empeg or two laying around, we (you and I) could just do a mainboard swap via the post. Let me know. We have at least six of them laying around here. Cheers Mark
Edited by mlord (29/11/2017 23:32)
|
|
Top
|
|
|
|
|
#369881 - 30/11/2017 01:35
Re: BlueGigaEmpeg
[Re: mlord]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Cool, thanks very much for that check information! My "friend" will do that voltage check on those pads when he gets home tonight. I do have a couple of spare Rio Car units, which I bought specifically for part situations like this, so I could do a mainboard swap for my "friend" if necessary. I'm hoping it won't come to that. In the meantime, on your copy of the BlueGiga development board, what does your continuity tester say for continuity between the SCK pin on the BlueGiga chip and the 3v rail? The 3v rail is the upper-left-most pin on the dev board, and you know where the SCK pin is. Since you have a working undamaged board+chip, I'm wondering if you see the same continuity between those as I do. If not, then I know that it's that part of my BlueGiga chip that's fried.
|
|
Top
|
|
|
|
|
#369883 - 30/11/2017 02:31
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
what does your continuity tester say for continuity between the SCK pin on the BlueGiga chip and the 3v rail? In the ballpark of 0.6 to 6.0 mega-ohms, but with some obvious large capacitance in there making an exact reading somewhat variable and dependent upon which way around the leads are connected.
|
|
Top
|
|
|
|
|
#369884 - 30/11/2017 05:07
Re: BlueGigaEmpeg
[Re: mlord]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Things bode well. My, er, my friend's, values are different than yours, but I'm getting voltages in the 1v-2v range on the SCK, WS and SDIN pins, and those voltages change depending on whether the empeg is paused or playing. The SDIN pin fluctuates on voltage as it's playing and is pretty steady when it's paused. It's a low voltage in the range of 1.4v when paused, and closer to 2v when it's playing. I think that tells me the empeg might be fine, and all my, er, my friend's, problems are entirely on the bluetooth chip.
Phew.
OK, now this raises the question of our design. What can we do to prevent other people from making the same mistake and frying their stuff too?
Or maybe we won't need to worry with our new pinout scheme. I wonder if the frying happened only because I, er, my friend, was using the old scheme with the RX/TX wires being used for the SCK and WS pins. Maybe with the new scheme this won't be a danger (maybe we'll luck out)?
The new scheme will have IISC on the originally unused purple wire, so there's no danger there for that one. IISW and IISD1 will be on Tuner Level and Tuner Signal. I wonder if that might fry the tuner but not the empeg if they did that? Dunno.
Anyway, live and learn, right?
|
|
Top
|
|
|
|
|
#369886 - 30/11/2017 05:51
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Okay, my next issue is a software issue, and I'm stumped. Usually when my car boots up and my bluetooth chip makes its initial connection to the head unit, I get PDU_REGISTER_NOTIFICATION's from the headunit for the following events: "PLAYBACK_STATUS_CHANGED", "TRACK_CHANGED", "GET_PLAY_STATUS", "GET_ELEMENT_ATTRIBUTES", I have no trouble responding to those, and they work well. I find each of the transaction labels from the headunit registering those messages, respond with an AVRCP NFY INTERIM command, and squirrel away the transaction labels for later use. Then later I can send a message up to the headunit saying "hey the playback status changed" or "hey the track changed" using those lablels, and it correctly either changes the play/pause indicator, or it queries me for the track metadata. All is well. Except... Lately it's been doing a thing where suddenly at initial connection it's begging for a whole bunch more NEW transaction types that I never saw it request before. I think this is because I improved the unit's initial connection speed and now it's more efficient, so it's coming into the process sooner and now my head unit has different behavior at connection time. I can't just "not respond" to these new messages. If I don't respond to them, it behaves badly, not issuing queries for track metadata, being slow with key press responses, etc. So I have to fix this and respond to all of these messages now somehow. The new messages that it's registering so far are: "TRACK_REACHED_END", "TRACK_REACHED_START", "PLAYBACK_POSITION_CHANGED", "BATT_STATUS_CHANGED", "SYSTEM_STATUS_CHANGED", "NOW_PLAYING_CHANGED", "AVAILABLE_PLAYERS_CHANGED"... There may be more than that coming up later, but I could only get that far in responding before it started hanging. Basically once I got a response to say "TRACK_REACHED_END" then it would start trying to register "TRACK_REACHED_START" then I'd have to respond to that, etc., and it's a vicious circle. The problem is I can't find any docs on their parameters for their responses! I'm having to guess! The AVRCP command reference here has detailed docs for responding to PLAYBACK_STATUS_CHANGED, TRACK_CHANGED, GET_PLAY_STATUS, and GET_ELEMENT_ATTRIBUTES just fine, but for all the others I only have their event IDs listed in section 6.3.3 of that Silicon Labs document. No details on how I respond with parameter details. I tried responding to all of them with a single 0 parameter, for example for "TRACK_REACHED_START" I tried responding with "AVRCP NFY INTERIM e 4 0" where: AVRCP NFY INTERIM - the response preamble. e - is the transaction label which changes with each query. 4 - the event ID for the event I'm responding to, in this case 4 means "TRACK_REACHED_START", which I got from section 6.3.3 of that document 0 - another parameter which is a total wild guess as to what the heck I'm supposed to respond with because there's no docs on it. That seemed to work for most of them, up until the last two (so far): "NOW_PLAYING_CHANGED" "AVAILABLE_PLAYERS_CHANGED" That response pattern doesn't work for those and I can't figure out how to respond to them in the BlueGiga command language. Everything I try results in SYNTAX ERROR and a badly-behaving headunit. Googling hasn't helped me find the parameter set for those two commands. And I expect when I finally get those responding with parameters it's going to start asking me for more, possibly all the other events listed in that table in section 6.3.3 of that Silicon Labs document. What I really want to know is how to REJECT some of those registration notifications. And I can't find how to REJECT in the BlueGiga command language. I know it can be done because I see other bluetooth software out there which does indeed do rejections to these commands. For example, search for "AVRC_RSP_REJ" here and you'll see that there's a way to do it, but I can't find out how that's implemented in the BlueGiga command language. I've tried various random syntactical things but they all produce SYNTAX ERROR when I try them. Hm. I'm getting SOME inforamation from here but not all of the info I need, and of course not in the BlueGiga language. Still digging.
|
|
Top
|
|
|
|
|
#369887 - 30/11/2017 07:13
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
The AVRCP specification states there should be either a REJECTED and/or a NOT IMPLEMENTED response available for these. However I can't find any documentation of the syntax for either of those commands in the iWrap command language.
|
|
Top
|
|
|
|
|
#369889 - 30/11/2017 14:07
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
What can we do to prevent other people from making the same mistake and frying their stuff too? Its not just I2S, but also the serial RX/TX pins in my case. We can add circuitry inside the empeg to tristate the I2S outputs when Bluetooth is not connected. This would consist of some MOSFET transistors and a resistor or three, plus a signal to enable those outputs when needed. The tricky bit is, from where do we get that signal? It can be software controlled once I find a spare output pin somewhere, or manually controlled with a switch/button. Or perhaps something more passive might work, such as diodes to prevent reverse current on those pins. That's easy enough for the empeg, but something similar should be done for the tuner as well: perhaps inline diodes on the tuner's half of its wiring harness. Nice and safe then, just need to ensure the voltage drop (from the diodes) isn't excessive. The new scheme will have IISC on the originally unused purple wire, so there's no danger there for that one. IISW and IISD1 will be on Tuner Level and Tuner Signal. I wonder if that might fry the tuner but not the empeg if they did that? Could fry either/both. I think diodes might be the way to go. Or, just put the new/smaller BT breakout module inside the empeg, so that it doesn't need I2S connections on the tuner wires. Will still have to do something similar for the serial connection though, either MOSFETs or diodes to prevent the same issues on those wires. I'll be on Christmas break starting three weeks from now, and hope to take a really good look at things then. Perhaps there may be a feasible way to add another dedicated serial port to the empeg for just the BT module. One crazy scheme bouncing around in my skull is to stuff an ESP8266 module inside there, and perhaps connect to the the empeg via a 4/8 bit parallel connection by plugging into the IDE cable. That would give enough bandwidth for comms between it and the empeg, and then it could easily manage most of the BT housekeeping duties on its own. If you haven't yet discovered the ESP8266, well.. it's a nice fast micro-controller with built-in WiFi-N, 14 I/O pins, tons of RAM and flash memory, and can be programmed using the Arduino tools/libraries. It's also about the size of a small postage stamp, though it gets larger once soldered to a breakout board (similar to the BT breakout you found). A nice side effect of embedding one of these, is that we could also use it to give the empeg a WiFi interface.
|
|
Top
|
|
|
|
|
#369890 - 30/11/2017 14:24
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
Or sometimes I wonder about slightly more invasive surgery.. such as installing a USB host controller chip inside the empeg. With that, once could then just plug-in all manner of things, including the BT-module, an ESP8266 module, etc.. Except the empeg's base kernel is WAY too old, and lacks the device drivers needed for anything other than a keyboard or mouse.
|
|
Top
|
|
|
|
|
|
Previous Topic
Index
