Unoffical empeg BBS

Quick Links: Empeg FAQ | Software | RioCar.Org | Hijack | jEmplode | emphatic
Repairs: Repairs | Addons: Eutronix | Cases

Page 8 of 17 < 1 2 ... 6 7 8 9 10 ... 16 17 >
Topic Options
#370044 - 10/12/2017 18:27 Re: BlueGigaEmpeg [Re: tfabris]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31149
Loc: Seattle, WA
I found that if I hold down the RESET button while applying power to the Betz board, that the problem goes away for a while. I wonder if it's related to how the DTR line on the FTDI UART is connected to the RESET pin on the bluetooth chip through a capacitor. Perhaps that capacitor is building up a charge some of the time and it needs to get discharged once in a while by holding down the reset button.

http://www.betztechnik.ca/uploads/2/5/6/7/25674051/wt32i.pdf
_________________________
Tony Fabris

Top
#370045 - 10/12/2017 18:32 Re: BlueGigaEmpeg [Re: tfabris]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 13867
Loc: Canada
Originally Posted By: tfabris
Perhaps that capacitor is building up a charge some of the time and it needs to get discharged once in a while by holding down the reset button.


I think that part is okay. It certainly doesn't have any bad effects here, at least.

But again, my board behaves like yours only when I forget to remove power from the FTDI chip while using the TX/RX pins from the I/O header. Or maybe when I get TX/RX reversed (oops!).

Top
#370046 - 10/12/2017 18:33 Re: BlueGigaEmpeg [Re: mlord]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31149
Loc: Seattle, WA
Quote:
I wonder why it wants a phone book download from an audio device?


It thinks (or perhaps just assumes) that your device is a phone.

When I pair, my stereo asks a similar question about whether I want the car to automatically make an emergency phone call if the car detects that it got in a wreck.

Perhaps I have the Bluetooth Class of Device wrong?

Quote:
The iWRAP stuff says the code just has to send OK in response to such, as in:
SSP CONFIRM a0:56:b2:4c:66:30 OK
So I added a line to the table to do that automatically, and it does it.


If you haven't already tried this, see if adding the other code I suggested above (spitting the line back including the number instead of the OK) works, *instead* of the OK line added to the table?
_________________________
Tony Fabris

Top
#370047 - 10/12/2017 18:35 Re: BlueGigaEmpeg [Re: mlord]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31149
Loc: Seattle, WA
Originally Posted By: mlord
I think that part is okay. It certainly doesn't have any bad effects here, at least.


Mine only develops this problem once in a while. It only happened this time after I had owned the board for a while and it had been working fine for a couple of days.

Quote:
But again, my board behaves like yours only when I forget to remove power from the FTDI chip while using the TX/RX pins from the I/O header. Or maybe when I get TX/RX reversed (oops!).


None of those things are the case in my situation. I have double checked that the jumper to the FTDI chip power does not have continuity.
_________________________
Tony Fabris

Top
#370048 - 10/12/2017 18:52 Re: BlueGigaEmpeg [Re: tfabris]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 13867
Loc: Canada
Originally Posted By: tfabris
Quote:
The iWRAP stuff says the code just has to send OK in response to such, as in:
SSP CONFIRM a0:56:b2:4c:66:30 OK
So I added a line to the table to do that automatically, and it does it.


If you haven't already tried this, see if adding the other code I suggested above (spitting the line back including the number instead of the OK) works, *instead* of the OK line added to the table?


Sending OK results in successful pairing, at least until after the phonebook question. If we send it with a PIN rather than OK, then I believe that amounts to asking the head-unit to confirm our (supplied) PIN (to which it should then respond with OK). Shouldn't be needed, but perhaps I'll try it anyway just for the heck of it.


Edited by mlord (10/12/2017 18:53)

Top
#370052 - 10/12/2017 23:33 Re: BlueGigaEmpeg [Re: mlord]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31149
Loc: Seattle, WA
I'm getting some similar behavior to what your output is showing, and this is on my plain old bluetooth headset. Oddly it never did this before it usually Just Paired Fine.

So I think maybe the issue is in my pairing code not correctly responding to certain messages and I need to work on this some more. Working on it now...
_________________________
Tony Fabris

Top
#370053 - 11/12/2017 00:35 Re: BlueGigaEmpeg [Re: tfabris]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31149
Loc: Seattle, WA
There's some weird stuff going on. If I don't do a "RESET" right before going into pairing mode, then the pairing process behaves weird and doesn't always work. I'm not sure if the code version you've got is doing that step correctly. I think it should have been, but I'm not certain. I've got an update to the code which changes a few things around in terms of where certain things are getting reset, and changes the reset timings. Maybe that will help.

There are also some minor bug fixes I made in other spots but I don't think those should have affected your situation either, based on looking at your output.

I also added your PIN confirmation "OK" message into the table just in case.

In any case, get the latest code from GitHub and see if it improves things - Probably not, but worth a try.

PS: In your "hand-typed" example of the pairing process, there was a thing where you got a "PAIR <bt:address> OK" message but you didn't respond with a CALL statement to connect A2DP so I'm not sure that hand-typed example was valid. Here's an example of my latest pairing process (it's preceded by some new timings for resets and such) so here's what a successful one looks like, though my output doesn't need the PIN confirmations.

--> INQUIRY 30
INQUIRY_PARTIAL 0c:e0:e4:6c:75:68 240404
------------------------------------
Pairing with device address:
0c:e0:e4:6c:75:68
------------------------------------
--> PAIR 0c:e0:e4:6c:75:68
INQUIRY 1
INQUIRY 0c:e0:e4:6c:75:68 240404
PAIR 0c:e0:e4:6c:75:68 OK
--> CALL 0c:e0:e4:6c:75:68 19 A2DP
CALL 0
CONNECT 0 A2DP 19
--> CALL 0c:e0:e4:6c:75:68 17 AVRCP
CALL 1
CONNECT 1 AVRCP 17
CONNECT 2 A2DP 19
--> A2DP STREAMING START
--> CALL 0c:e0:e4:6c:75:68 17 AVRCP
AVRCP 1 GET_CAPABILITIES 2
--> AVRCP RSP
A2DP STREAMING START 0
--> A2DP STREAMING START
Empeg state...................................PLAYING >
AUDIO ROUTE 0 A2DP LEFT RIGHT
Detected: Pairing Mode is Complete.
--> SET CONTROL RECONNECT 600 0 0 7 0 A2DP A2DP AVRCP
STORECONFIG
CALL 3
_________________________
Tony Fabris

Top
#370055 - 11/12/2017 02:43 Re: BlueGigaEmpeg [Re: tfabris]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31149
Loc: Seattle, WA
If you try it again with the latest software (I predict the problem will still occur), type "set" in the console after having encountered the error, then post a full log of the entire session.

Also interested in knowing if, after it fails to pair, what happens if you just turn everything off and back on again. Does it connect then? sometimes I've had that happen after a pairing problem.
_________________________
Tony Fabris

Top
#370061 - 11/12/2017 18:06 Re: BlueGigaEmpeg [Re: tfabris]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31149
Loc: Seattle, WA
Unrelated to your pairing issues, there is some kind of a connection bug which is making the headunit re-query for track title data in a continuous fast loop. This makes updates slow overall.

https://github.com/tfabris/BlueGigaEmpeg/issues/5

Investigating this.
_________________________
Tony Fabris

Top
#370062 - 11/12/2017 18:08 Re: BlueGigaEmpeg [Re: tfabris]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 13867
Loc: Canada
Funny! Bug, or just behaving like Google Location Services? smile

I hope to have another go at it tonight.

Thanks!

Top
#370065 - 11/12/2017 23:55 Re: BlueGigaEmpeg [Re: mlord]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31149
Loc: Seattle, WA
Sanity checking something:

When running the empeg on the test bench from a 12v DC wall wart power supply (wired through the sled), everything works as expected.

I notice that some of the chips on the empeg mother board get slightly warm after running for a while. Not alarmingly warm, just cozy like being under a blanket.

The ones I notice getting warm are:
- The StrongArm CPU
- Philips SA7705H/203
- Crystal CS4231A-KQ

That's normal, correct?

(Checking because I want to make sure that my I2S wiring hack isn't hurting anything long term.)
_________________________
Tony Fabris

Top
#370069 - 12/12/2017 04:54 Re: BlueGigaEmpeg [Re: tfabris]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31149
Loc: Seattle, WA
I've made some more minor code updates this evening.

The most important one that you need to know about is the one called KillAllLogging where there's a global flag variable in the code which controls whether or not any logging is made to the debug serial port. For what you're doing you'll want that feature turned off while you're debugging.

When you turn it on, the debug serial port is silent, which saves some cycles and speeds up the conversations with the host stereo a tiny bit.
_________________________
Tony Fabris

Top
#370071 - 12/12/2017 13:50 Re: BlueGigaEmpeg [Re: tfabris]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 13867
Loc: Canada
Originally Posted By: tfabris
The ones I notice getting warm are:
- The StrongArm CPU
- Philips SA7705H/203
- Crystal CS4231A-KQ

That's normal, correct?


Yup. Very normal for that generation of chips.

Top
#370076 - 13/12/2017 02:42 Re: BlueGigaEmpeg [Re: mlord]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31149
Loc: Seattle, WA
Awesome. Thanks!

When you get back to trying this, I recommend trying to mess around with the Device Capabilities and the Bluetooth Class Of Device settings to see if that makes the head unit behave more nicely with the chip.
_________________________
Tony Fabris

Top
#370078 - 13/12/2017 04:16 Re: BlueGigaEmpeg [Re: tfabris]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31149
Loc: Seattle, WA
Anyone know this one?

Is it normal (aka a known behavior) for the player to output three copies of the current track info when you press Down Down Down on the front panel? That's what I'm getting when I shuffle the whole player: Three repeats of the track metadata out the serial port.

Even with the reduction in size of the track string length that was added in Hijack 522, repeating the block of text three times overflows my serial buffer in frequent cases, causing garbled track titles getting sent up the bluetooth.

Just wondering if that's just me or if that happens to everyone.
_________________________
Tony Fabris

Top
#370079 - 13/12/2017 04:49 Re: BlueGigaEmpeg [Re: tfabris]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31149
Loc: Seattle, WA
Did I say three? It's actually four. smile
_________________________
Tony Fabris

Top
#370082 - 13/12/2017 14:04 Re: BlueGigaEmpeg [Re: tfabris]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 13867
Loc: Canada
Ha! Well, easy workaround anyway. If you already have track data for the "new" FID (ie. same FID as you already have stored), then just discard?

I think we really need to get this inside the empeg, where the serial buffers are 4KB, the processor is much more capable, and so on.

Except I'm unlikely to do it until after I get BT working here (difficult to test otherwise).

Cheers


Edited by mlord (13/12/2017 14:05)

Top
#370083 - 13/12/2017 14:07 Re: BlueGigaEmpeg [Re: mlord]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 13867
Loc: Canada
Originally Posted By: mlord
Ha! Well, easy workaround anyway. If you already have track data for the "new" FID (ie. same FID as you already have stored), then just discard?


For that matter, I can do this in Hijack instead, so that the duplicates never arrive: http://rtr.ca/hijack.zImage .. Not sure if that's better or not, but probably! smile

Untested (gotta run for a dentist appointment).


Edited by mlord (13/12/2017 14:13)

Top
#370087 - 13/12/2017 16:36 Re: BlueGigaEmpeg [Re: mlord]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31149
Loc: Seattle, WA
I will try it tonight!

What method are you using to suppress the additional outputs?

If itís one line at at time (donít send the line out the serial port if it matches the prior one) then that might be a problem since I cue off the Genre line (itís always the last one)
_________________________
Tony Fabris

Top
#370088 - 13/12/2017 16:56 Re: BlueGigaEmpeg [Re: tfabris]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31149
Loc: Seattle, WA
Forgot to say: thanks so much for doing that! Iím looking forward to trying it when I get home tonight!
_________________________
Tony Fabris

Top
#370089 - 13/12/2017 18:58 Re: BlueGigaEmpeg [Re: tfabris]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 13867
Loc: Canada
Originally Posted By: tfabris
What method are you using to suppress the additional outputs?


Initially, I tried to suppress it on a "group of lines" basis. But it quickly became apparent that this wouldn't really work well, or at least not the way I was implementing it. Things just got too complex for too simple a problem. smile

I have re-done it now, and TESTED it this time too.
Now, it only outputs a line if the value of the line has changed.

So triggering something on "Genre", or any line other than the ones starting with 'F', isn't going to work any longer.

Rather than triggering on "the final line of the attributes" (formerly Genre), instead you could trigger on the first '#' line after an 'F' line, which gives the same effect.

[EDIT]
Or you could just trigger on any '#' line that begins with a FID that differs from the previous '#' line. Same idea, possibly simpler.
[/EDIT]

A bit of short-term pain (my apologies for that), but the end result is much better I think.

Cheers!


Edited by mlord (13/12/2017 19:08)

Top
#370090 - 13/12/2017 20:04 Re: BlueGigaEmpeg [Re: mlord]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31149
Loc: Seattle, WA
Mark, thanks so much for doing all this stuff to Hijack for this project. It's super helpful.

Quote:
Initially, I tried to suppress it on a "group of lines" basis. But it quickly became apparent that this wouldn't really work well, or at least not the way I was implementing it. Things just got too complex for too simple a problem.


Yep, I figured it would be like that.


Quote:
Now, it only outputs a line if the value of the line has changed.


Sensible, but, as you said, makes my detection code more complicated. For something like this, the complexity would have to be either in my code or yours. smile


Question:

Does your new change which "only outputs if the value changed" include the timestamp lines and the paused/playing lines (the # and S lines)? If so, you probably shouldn't do the special casing for those, and instead just output those as-is.

Because there is a workaround in my interpreter code (see approx line 3678 in the current code) which works around a player bug which depends on the timestamp lines updating normally. The bug was that sometimes the empeg player application would not send an "S1" or "S0" when pausing or unpausing, so my code also keyed off whether or not the timestamps were changing or staying the same in order to update the host stereo on the play/paused state (partly because you suggested that very thing as a workaround).


Quote:
instead you could trigger on the first '#' or 'S' line after an 'F' line, which gives the same effect.


Not exactly. As mentioned above, waiting for an "S" line might never come thanks to the player application bug, and waiting for a "#" line would delay my output by the amount of time that I had to wait for it, and those only come once per second.. and only if the player is playing; if the player is paused then it will never come (I think).

I'm already dealing with the fact that the track title updates on the host stereo screen are coming slower than I want them to come, and waiting for S or # would cause me to have to wait as much as another 1000 milliseconds before being able to update the host. That's an eternity for this particular thing. I've been using this in my car for the last several days, and in actual practice, slow track title updates are a major pain point that I'm trying very hard to fix right now.

I have to think more about the correct/timely way to do this.

One of the issues is that some stereos query for the entire track metadata all at once on one line, others query for it piecemeal (but still all at the same time) so the data conversation for updating the track metadata is an exchange of several messages back and forth. But the host stereo doesn't even begin the query until I notify it that a track has been changed. The current conversation goes like this:

1. At first connection, host stereo sends me a PDU_REGISTER_NOTIFICATION for TRACK_CHANGED.

2. I respond with "NFY INTERIM" details that say yes, I'll notify you if tracks change.

3. I collect track data change information from the empeg which, on the empeg, comes out one line at a time. Up till now, it would always come out in a predictable block always ending with the Genre tag.

4. Once I'm sure I have all of it, I send a SINGLE message to the host stereo saying "TRACK_CHANGED".

5. Host stereo queries me for track metadata. Sometimes it's asking for all the track data combined in one long message, or sometimes it's several messages in quick succession for different piecemeal parts of it, but either way it all happens together in one message or one group of messages. In other words, if I say to the host stereo "TRACK_CHANGED", I don't get to tell it which piece of the track changed, I can only tell it that the entire track changed. So the host always queries for all the track data all at once.

In other words, the host stereo might say "Send me title. Now send me genre. Now send me artist. Now send me track number. Now send me playlist length. Now send me duration... etc.", or it might say "send me track number, playlist length, and duration all in one line. Now send me title, artist, album, and genre all in one line", or it might say "send me everything all in one line". But because I don't get to tell it which bits changed, it has no way of knowing which parts are new and which parts are the same. So the host stereo always queries for all of the bits all in one group in quick succession, and I must respond to all of its queries immediately or the AVRCP connection will hang.

That's why in step number 4, I have to wait until I know all the track data has gotten to me before notifying the host stereo to start querying more that data. Because if I notify the host stereo too early, say, perhaps I do it only when I get a new Track Title, then the host stereo will query too early and then I will send it a partially messed up set of track metadata, containing the track title from the current track, but other pieces of metadata from the prior track. Maybe the metadata will be re queried again a few moments later when I get another line from the empeg, and then eventually what's displayed on the screen will be correct, but, in the meantime there will be a problem where the touchscreen displays the correct track title but some of the other data will be wrong.

Also in step number 4, I believe that I should make sure to not spam the host stereo with multiple updates about the track metadata. For instance, I should not send the host stereo a new "TRACK_CHANGED" message for every changed line of metadata that I receive from the empeg. I think this would cause too many sequential messages all at once causing too much back and forth between me and the host, and slowing down the responsiveness of the track title update process. Because that means the entire exchange in step 5 would have to be repeated several times for each line of new data that I get from the empeg.

So that's why I wait until I have all track the data before I try sending it up the bluetooth. Also, it is why I was so excited to discover that the empeg player application RELIABLY sent me the genre tag as the last line in the group every time. That made it very easy to key off of, and the updates were "fairly" quick.

However, as it is, there's something like 500-1000ms of delay between the time I press "next track" and the new track appears on the car stereo touchscreen, and that's already too long for my tastes. Having to wait for the next "S" or "#" message (which may never come) will add at least another 1000ms to that. That would be a problem I think.

ON THE OTHER HAND.........

Maybe doing it piecemeal is the correct solution. Maybe sending new TRACK_CHANGED notifications for each line of metadata received from the empeg, and having me and the host stereo re-spam each other several times for each one, is really the correct and most responsive way to get the job done. I'm certainly willing to TRY it. My prediction is that it will be slower and that it will look bad, but maybe it will actually be better. I can certainly give that a try with your current code.

But if it ends up being worse, then I'd prefer to just have you revert that set of Hijack changes you just made, put it back to V522, and then I will find other ways to work around the "player sends four track updates when reshuffling the whole player" bug.

Thanks again for doing all this work on Hijack, it's so massively helpful, and I'm sorry it's getting complicated.
_________________________
Tony Fabris

Top
#370093 - 13/12/2017 22:59 Re: BlueGigaEmpeg [Re: tfabris]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 13867
Loc: Canada
I'm not convinced that the player omits the 'S' lines. You ran into that problem back before discovering the undersized serial buffers, and it probably has "gone away" since then.

Or has it?

Top
#370097 - 14/12/2017 01:04 Re: BlueGigaEmpeg [Re: mlord]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31149
Loc: Seattle, WA
You make a good point. But I'm pretty sure that I had cleanly reproduced it unrelated to the serial buffer issue. You're right that I should look again though.
_________________________
Tony Fabris

Top
#370099 - 14/12/2017 01:17 Re: BlueGigaEmpeg [Re: tfabris]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 13867
Loc: Canada
If it helps, I can special case the 'G' lines, and always allow them through, changed or unchanged.

Most of the delay in metadata is for the Source ("Album", the 'Z' line) lookups. Those happen immediately upon recept of an 'F' line, and often result in waiting for the drive to spin up so that Hijack can read the tag file. This adds a 1+ second delay before the rest of the track data appears.

Were I to throw that into a background task, or not do the lookup until after the 'G' line, the available data would come out right away, and then later be followed by a new 'Z' line (and new 'D' line). But doing that is of limited value if the code remains fixated on having all data present when 'G' appears.

???

Top
#370101 - 14/12/2017 01:28 Re: BlueGigaEmpeg [Re: tfabris]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 13867
Loc: Canada
My experiments just now indicate that a new '#' line is issued immediately after 'G' on any track change, so you might not need the 'G' lines to be "always allowed through".

Top
#370104 - 14/12/2017 01:45 Re: BlueGigaEmpeg [Re: mlord]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31149
Loc: Seattle, WA
Cool. I'll experiment with things tonight using your current code and see where we fall. Thanks so much!
_________________________
Tony Fabris

Top
#370105 - 14/12/2017 01:49 Re: BlueGigaEmpeg [Re: tfabris]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 13867
Loc: Canada
I'm sure we'll get it working well in the end!

Top
#370107 - 14/12/2017 02:36 Re: BlueGigaEmpeg [Re: tfabris]
jmwking
addict

Registered: 27/02/2003
Posts: 678
Loc: Washington, DC metro
I'd like to say it's been fun watching this play out.

thanks!

-jk

Top
#370108 - 14/12/2017 04:25 Re: BlueGigaEmpeg [Re: jmwking]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31149
Loc: Seattle, WA
Thanks! I'm glad we've been keeping the development public on the boards, then.

Developing bluetooth stuff like this is a lot harder than I thought it would be, but it's been really interesting, so I'm hoping that this information helps someone someday.
_________________________
Tony Fabris

Top
Page 8 of 17 < 1 2 ... 6 7 8 9 10 ... 16 17 >