#370109 - 14/12/2017 04:50
Re: BlueGigaEmpeg
[Re: mlord]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31599
Loc: Seattle, WA
|
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". Did you try your experiment when the player is paused as well? My experiments show that when the player is paused that I get nothing except the track titles on track changes (lines N F Z D T A G in that order), so G is really the last thing I get in that case. I haven't tried it with your new Hijack yet, that's just with version 522. I'll try it with your new Hijack next.
|
|
Top
|
|
|
|
|
#370110 - 14/12/2017 04:53
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31599
Loc: Seattle, WA
|
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. I'm on an SSD, so is the spinup time expected to be a factor then? When looking directly at the player's serial port with a terminal program (no BlueGiga in the mix), each press of the "next track" button on the player results in an essentially instantaneous spew of every single line of all the track metadata with Hijack v522. Getting ready to try the newer hijack with the "no repeats" feature.
|
|
Top
|
|
|
|
|
#370111 - 14/12/2017 04:59
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31599
Loc: Seattle, WA
|
Okay interesting. Still on V522 I have noticed that the "pause" getting the Z line after the F line is happening only when the track is playing. When the player is paused the track data appears instantaneously. In any case, if it's a choice between no album title and fast track updates, I'll take the album title. 
|
|
Top
|
|
|
|
|
#370114 - 14/12/2017 06:58
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31599
Loc: Seattle, WA
|
Verdict:
- Your latest Hijack code is good, I think, in my initial tests. Needs a bit more bake time but initial tests are very promising.
- I don't have to wait for anything. I simply send the track change notification with every single line of the metadata. So the host stereo gets several of those in a row in quick succession with each new track change.
- My stereo seems to be smart about it and doesn't instantly query me for metadata for every single one. It seems to realize that I did a bunch in quick succession and then queries me once for them instead of a bunch of times. And it seems to do it with the correct timing. So my fears about spamming were unfounded.
- Things seem a bit slower now than they were before, in terms of track updates on the car stereo screen. But at the moment, I think that's on me for now. I have some ideas about how to handle that, I'll think about it.
- And, of course, it totally fixes the "down down down" bug which sends four copies of the track. Which was the thing that started this all.
THANK YOU!!!
More work to come, but the current code is updated on GitHub.
Okay, but here's a potential bug.
It's something that I wonder if this is Hijack, or if this is the player app having this issue. But I've seen it a few times now, and I've seen it in both Hijack V522 and also in the latest experimental version of Hijack as well. So I don't think it's related to your very latest changes, and I don't even know if it's related to Hijack at all or if it's related to 522 or what. Also, I've seen this with no BlueGiga connected (direct serial port connection to player with PUTTY) and also with the BlueGiga connected and viewing it through the Arduino debug console.
The bug goes like this:
- Several very fast presses of the top button on the player (pause, unpause, pause, unpause several times).
- Sometimes, not every time, all serial port output from the empeg stops, halts completely, silence.
- When this happens, additional presses of the pause button to not fix the issue, it's still silent on the serial port.
- If I am connected to the empeg Serial port directly with Putty, I can press ENTER on the serial port and it fixes the problem.
Anyway, let me know if you can repro that bug and if you think it's even related to Hijack at all.
Thank you!!!
|
|
Top
|
|
|
|
|
#370117 - 14/12/2017 09:27
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31599
Loc: Seattle, WA
|
Side topic: Anyone have suggestions for an inexpensive bluetooth receiver or speaker, which shows track titles, that I can use for bench testing? So I don't have to keep sitting in the car to test this? I don't necessarily want a big stereo receiver, I'm looking for something smaller. But there doesn't really seem to be much out there. I have considered getting a car or marine unit and powering it with a 12v adapter. Something maybe like this: Dual MGH30BT marine player - which I have confirmed with video does in fact display track titles... Some of the devices out there aren't very clear in their product specs as to whether or not they display track titles. For instance, the manual for that MGH30BT didn't say, and I had to search youtube for it. Any other ideas or suggestions, perhaps a portable speaker with BT track titles on an LCD display? I can't seem to find one but I know they must exist.
|
|
Top
|
|
|
|
|
#370121 - 14/12/2017 13:39
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14494
Loc: Canada
|
Okay, that's encouraging! Good Stuff.
I think I might change the sequence in Hijack ever so slightly, such that the "Source" and "Duration" fields get queried *after* most of the other track info has been passed along.
With a bit of luck, this should result in the track title appearing on-screen at the head unit a second or three sooner than it currently does.
|
|
Top
|
|
|
|
|
#370122 - 14/12/2017 13:50
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14494
Loc: Canada
|
Okay, but here's a potential bug. Ah yes, I am seeing that now for the first time here, and I have a pretty good idea of what to look for. Definitely caused by Hijack, I think, and only recently being noticed due to Hijack injecting extra lines at the serial port. I think it is somehow tossing data into the output FIFO without re-enabling the serial port TX interrupt in the cases where that interrupt is not already enabled. Hitting ENTER is a great clue, because that would trigger a serial RX interrupt, and the processing thereof would also re-enable TX. So I know where to look for it.
|
|
Top
|
|
|
|
|
#370125 - 14/12/2017 16:33
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14494
Loc: Canada
|
Okay, that took a bit of effort. Try this Hijack binary: http://rtr.ca/hijack.zImage
It should no longer be locking up the serial port (Yay!). You should also get the track/artist info onto the head-unit display a bit earlier than before too, because the Source (Album) and Duration are now read from the tag file _after_ the Genre line has been processed. Techie info: It was the reading of the tag file that was gumming up the serial port. So I restructured things a bit, and moved the call for that way way up higher in the stack. It was just not safe to do that in the context of the serial port driver. Cheers
Edited by mlord (14/12/2017 18:23)
|
|
Top
|
|
|
|
#370127 - 14/12/2017 17:16
Hijack v523 is released
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14494
Loc: Canada
|
Hijack v523 is now available.
-- Includes various bug fixes related to processing serial output from the player.
|
|
Top
|
|
|
|
|
#370130 - 14/12/2017 20:17
Re: Hijack v523 is released
[Re: mlord]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31599
Loc: Seattle, WA
|
Thanks so much, Mark!
I have noticed a small bug in Hijack V523: Not all of the track data is echoed to the serial port when the player is paused and you switch to a new track.
- The Z "source" line does not echo to the serial port when the player is paused.
- The D "duration" line does not echo to the serial port after the "N" line when the player is paused.
- When the player is paused, A D "duration" line appears *before* the N line very quickly but I am not certain whether it is the prior track's D line coming out finally, or if it is the correct D line for the current track.
- When the player is playing, everything is normal except that the Z and D lines appear slowly, sometimes taking a few seconds to appear after pressing next track. In your last update you seemed to think that you'd made them happen faster, but I still see a fairly long pause most of the times after I press Next Track.
Also:
I'm having another bug (only discovered late last night) which is happening as a secondary side effect of my code changes to work with the deduplication feature in v523. So I'm wondering if we should just go back to the old way. I can go into more detail on that bug if you like, but I think the bug would go away if we switched back to the old way of not deduplicating the serial port output.
I think the deduplication might be too complicated now and might be making more subtle and hard to find bugs appear. Initially I was able to work with it, but there are more things cropping up. The original reason you put in the deduplication feature, where it repeats the same track data four times, is something that I might be able to fix in my own code and not have to have Hijack be responsible for working around that player bug.
Thanks so much for working so hard on this with me. It's really awesome so far and I might make a video of my current setup soon.
|
|
Top
|
|
|
|
|
#370132 - 14/12/2017 21:15
Re: BlueGigaEmpeg
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14494
Loc: Canada
|
Progress.
...
--> SET BT NAME empeg Car
--> SET BT SSP 1 0
--> SET BT AUTH * 0000
--> SET CONTROL AUDIO INTERNAL I2S_SLAVE EVENT KEEPALIVE 16
--> SET CONTROL PREAMP 0 0
--> SET CONTROL MICBIAS 0 0
--> SET CONTROL GAIN 9 0
Done Setting Defaults.
--> RESET
SET CONTROL ESCAPE - 00 0
SET CONTROL ECHO 5
WRAP THOR AI (6.2.0 build 1122)
Copyright (c) 2003-2017 Silicon Labs Inc.
READY.
--------------------------------------
Done resetting. Beginning pair.
--------------------------------------
...
--> INQUIRY 30
INQUIRY_PARTIAL a0:56:b2:4c:66:30 760408
------------------------------------
Pairing with device address:
a0:56:b2:4c:66:30
------------------------------------
--> PAIR a0:56:b2:4c:66:30
INQUIRY 1
INQUIRY a0:56:b2:4c:66:30 760408
SSP CONFIRM a0:56:b2:4c:66:30 654947 ?
--> SSP CONFIRM a0:56:b2:4c:66:30 OK
PAIR a0:56:b2:4c:66:30 OK
--> CALL a0:56:b2:4c:66:30 0019 A2DP
CALL 0
CONNECT 0 A2DP 19
--> CALL a0:56:b2:4c:66:30 0017 AVRCP
CALL 1
CONNECT 2 A2DP 19
--> A2DP STREAMING START
--> CALL a0:56:b2:4c:66:30 0017 AVRCP
CALL 3
A2DP STREAMING START 0
Empeg state...................................PLAYING >
AUDIO ROUTE 0 A2DP LEFT RIGHT
Detected: Pairing Mode is Complete.
--> SET CONTROL RECONNECT 4800 0 0 7 0 A2DP A2DP AVRCP
STORECONFIG
--------------------------------------
Pairing process ended.
--------------------------------------
A2DP CODEC SBC JOINT_STEREO 44100 BITPOOL 2-53
NO CARRIER 3 ERROR 9004 L2CAP_CONNECTION_REJ_RESOURCES
Empeg state..................................PAUSED ||
CONNECT 1 AVRCP 17
AVRCP 1 GET_CAPABILITIES 3
--> AVRCP RSP 1 2
AVRCP 1 PDU_REGISTER_NOTIFICATION 1 PLAYBACK_STATUS_CHANGED 1
--> AVRCP NFY INTERIM 1 1 2
AVRCP 1 PDU_REGISTER_NOTIFICATION 2 TRACK_CHANGED 1
--> AVRCP NFY INTERIM 2 2 1
AVRCP 1 LIST_APPLICATION_SETTING_ATTRIBUTES
--> AVRCP RSP
AVRCP 1 LIST_APPLICATION_SETTING_ATTRIBUTES
--> AVRCP RSP
AVRCP 1 LIST_APPLICATION_SETTING_ATTRIBUTES
--> AVRCP RSP
AVRCP 1 LIST_APPLICATION_SETTING_ATTRIBUTES
--> AVRCP RSP
AVRCP 1 GET_ELEMENT_ATTRIBUTES 07 01 02 03 04 05 06 07?
--> AVRCP RSP 7 1 "Unknown track on empeg Car" 2 "Unknown artist on empeg Car" 3 "(Album N/A)" 4 "00" 5 "99999" 6 "Unknown genre on empeg Car" 7 "00"
AVRCP PLAY PRESS
--> AVRCP NFY CHANGED 1 1 1
--> AVRCP NFY CHANGED 2 2 1
Empeg state...................................PLAYING >
--> A2DP STREAMING START
AVRCP PLAY RELEASE
AVRCP 1 PDU_REGISTER_NOTIFICATION a PLAYBACK_STATUS_CHANGED 1
--> AVRCP NFY INTERIM a 1 1
AVRCP 1 PDU_REGISTER_NOTIFICATION b TRACK_CHANGED 1
--> AVRCP NFY INTERIM b 2 1
AVRCP 1 GET_ELEMENT_ATTRIBUTES 07 01 02 03 04 05 06 07?
AVRCP 1 GET_ELEMENT_ATTRIBUTES 07 01 02 03 04 05 06 07?
--> AVRCP RSP 7 1 "Unknown track on empeg Car" 2 "Unknown artist on empeg Car" 3 "(Album N/A)" 4 "00" 5 "99999" 6 "Unknown genre on empeg Car" 7 "00"
... Whoops.. empeg not powered on yet ...
First timestamp received from empeg Car - Not performing play-pause state change code just yet.
--> AVRCP NFY CHANGED 6 1 2
--> AVRCP NFY CHANGED 7 2 1
Empeg state..................................PAUSED ||
AVRCP 1 PDU_REGISTER_NOTIFICATION d PLAYBACK_STATUS_CHANGED 1
--> AVRCP NFY INTERIM d 1 2
AVRCP 1 PDU_REGISTER_NOTIFICATION e TRACK_CHANGED 1
--> AVRCP NFY INTERIM e 2 1
AVRCP 1 GET_ELEMENT_ATTRIBUTES 07 01 02 03 04 05 06 07?
AVRCP 1 GET_ELEMENT_ATTRIBUTES 07 01 02 03 04 05 06 07?
--> AVRCP RSP 7 1 "Keep Yourself Alive" 2 "Queen" 3 "Classic Queen" 4 "83" 5 "99999" 6 "Rock" 7 "0"
--> AVRCP NFY CHANGED d 1 2
--> AVRCP NFY CHANGED e 2 1
Empeg state..................................PAUSED ||
AVRCP 1 PDU_REGISTER_NOTIFICATION 1 PLAYBACK_STATUS_CHANGED 1
--> AVRCP NFY INTERIM 1 1 2
AVRCP 1 PDU_REGISTER_NOTIFICATION 2 TRACK_CHANGED 1
--> AVRCP NFY INTERIM 2 2 1
AVRCP 1 GET_ELEMENT_ATTRIBUTES 07 01 02 03 04 05 06 07?
AVRCP 1 GET_ELEMENT_ATTRIBUTES 07 01 02 03 04 05 06 07?
--> AVRCP RSP 7 1 "Wishing On The Moon" 2 "Dan Fogelberg" 3 "Classic Queen" 4 "84" 5 "11421" 6 "Rock" 7 "0"
--> AVRCP NFY CHANGED 1 1 2
--> AVRCP NFY CHANGED 2 2 1
Empeg state..................................PAUSED ||
--> AVRCP NFY CHANGED 1 1 2
--> AVRCP NFY CHANGED 2 2 1
Empeg state..................................PAUSED ||
--> AVRCP NFY CHANGED 1 1 1
--> AVRCP NFY CHANGED 2 2 1
Empeg state...................................PLAYING >
AVRCP 1 PDU_REGISTER_NOTIFICATION 5 PLAYBACK_STATUS_CHANGED 1
--> AVRCP NFY INTERIM 5 1 1
AVRCP 1 PDU_REGISTER_NOTIFICATION 6 TRACK_CHANGED 1
--> AVRCP NFY INTERIM 6 2 1
AVRCP 1 GET_ELEMENT_ATTRIBUTES 07 01 02 03 04 05 06 07?
--> AVRCP RSP 7 1 "Wishing On The Moon" 2 "Dan Fogelberg" 3 "Phoenix" 4 "84" 5 "11421" 6 "Rock" 7 "0"
AVRCP 1 GET_PLAY_STATUS
...
Full log (larger than the above) is attached.
Edited by mlord (14/12/2017 21:25)
|
|
Top
|
|
|
|
|
#370133 - 14/12/2017 21:20
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14494
Loc: Canada
|
This was latest -git as of earlier this afternoon, with minimal changes.
-const String btAuthTypeString = "SET BT SSP 3 0";
+const String btAuthTypeString = "SET BT SSP 1 0";
..
-boolean KillAllLogging = true;
+boolean KillAllLogging = false;
..
- { " OK", "CALL {0} 19 A2DP"},
+ { " OK", "CALL {0} 0019 A2DP"},
..
- { "CONNECT 0 A2DP 19", "CALL {0} 17 AVRCP"},
- { "CONNECT 1 A2DP 19", "CALL {0} 17 AVRCP"},
- { "CONNECT 2 A2DP 19", "CALL {0} 17 AVRCP"},
+ { "CONNECT 0 A2DP 19", "CALL {0} 0017 AVRCP"},
+ { "CONNECT 1 A2DP 19", "CALL {0} 0017 AVRCP"},
+ { "CONNECT 2 A2DP 19", "CALL {0} 0017 AVRCP"},
The iWRAP document shows 4-digit hex for the numbers (19,17) so I padded with zeros to get 4-digits. Will test again later to see if that was really needed or not. The track info on the head-unit tends to be very out-of-sync with the empeg at present, but I'm hoping this will get better after you play with today's Hijack release. Excited! Thanks for everything thus far!! Oh, and I'm also noticing the BT breadboard has some kind of reset issue -- need to push the button on it _sometimes_ after power-up. Should be fixable.
Edited by mlord (14/12/2017 21:27)
|
|
Top
|
|
|
|
|
#370134 - 14/12/2017 21:32
Re: BlueGigaEmpeg
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14494
Loc: Canada
|
Oh, and I'm also noticing the BT breadboard has some kind of reset issue -- need to push the button on it _sometimes_ after power-up.
Should be fixable. Yeah, there's no real reset circuitry on that board -- it relies on the FTDI chip normally, with the host toggling DTR to reset the board. So we can do the same thing, using a GPIO pin on the Arduino, connected to the RST pin on the breadboard header. Gotta be careful again about not feeding +5V there. I'll have a quick go at it and report back.
|
|
Top
|
|
|
|
|
#370135 - 14/12/2017 21:57
Re: BlueGigaEmpeg
[Re: mlord]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31599
Loc: Seattle, WA
|
I'm excited that you have been making progess and that you have a connection! I'm glad that it was as simple as changing the security setting. Regarding the 2-digit versus 4-digit numbers for the L2CAP PSM codes (0019 and 0017 versus 19 and 17): My experience has been that the iWrap command language simply interprets whatever numbers you give it and turns them into the correct numeric values under the hood. I know that the docs say the digit format is "XXXX" for those number, but then, if you look at their own examples of how the code is used, they use two digits for those numbers in all their examples. I'm not clear on how they decide about the difference between hex numbers and decimal numbers. I think that their interpreter expects certain parameters to be either hex or decimal depending on what the parameter is "supposed to be" and does the conversion with the assumption that you used the correct format. Regarding the reset button needing to be pushed "some" of the time, that was the initial thing that I experienced and talked about a few days ago. I like your idea of using a GPIO pin on the arduino to handle it (probably via another voltage divider I'm guessin), should that truly become necessary. However the reset button thing stopped being a problem for me once I realized something: - When I am powering the whole assembly purely via the Arduino USB debug cable, then the BlueGiga chip isn't always getting enough power for it to fully wake up automatically, so it's dark sometimes. Pressing its reset button usually wakes it up at that time, but it's kinda getting less juice than I would want it to get. - On the other hand, if I power the Bluetooth board assembly via 5v obtains from empeg's power indirectly through the tuner connector and then through that Pololu power supply, then it always (at least for me) seems to get enough juice to fully power up. - Empeg doesn't supply power to the tuner connector when asleep, so make sure the empeg is not asleep. So my procedure for powering things up is: - If I'm not debugging it, unplug the debug cable and just get the power from the Empeg's 12v power through the Pololu. - If I am debugging it, connect the Arduino debug cable first so that the computer correctly detects the presence of the USB port, then immediately after that, apply power to the empeg. - Make sure the empeg is not asleep. I'm excited to learn what changes you're making for a Hijack release today. I hope that it's simply not doing the deduplication, because I'm pretty sure that's going to be the best solution. By the way, here are the two bugs I get because I'm having to work with the deduplication: https://github.com/tfabris/BlueGigaEmpeg/issues/10https://github.com/tfabris/BlueGigaEmpeg/issues/9I'm also considering a change to the logging. Let me know what you think of this: https://github.com/tfabris/BlueGigaEmpeg/issues/11
|
|
Top
|
|
|
|
|
#370136 - 14/12/2017 21:59
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31599
Loc: Seattle, WA
|
By the way, if you try the code without the deduplication, the only change that needs to be made to BlueGigaEmpeg should be putting the "if" statement back around this line at approximately line number 3470 of the code. (I think, haven't tested it yet.)
// Originally this was set this only when we get a "Genre" change ("G")
// since that is the last of the track information sets to appear on the
// serial port in a block of messages. However now we have to do it every
// time because of the deduplication that Mark Lord is doing in the new
// Hijack. Genre might not come out any more. Currently experimenting with
// simply doing this every time.
//
// Experiment: Going back to non-deduplication and triggering off of Genre
// again since I had other bugs related to V523's deduplication feature.
if (empegMessageCode == 'G')
{
HandleEmpegStateChange();
}
|
|
Top
|
|
|
|
|
#370137 - 14/12/2017 22:08
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14494
Loc: Canada
|
Reset using Arduino Pin 51 to the RST pin on the WT32i. Just a straight wire is all that's needed, because the internal PULLUP is weak enough to not hurt anything. void setup()
{
+ pinMode(51, INPUT_PULLUP);
+ delay(300);
+ digitalWrite(51, LOW);
+ pinMode(51, OUTPUT);
+ digitalWrite(51, LOW);
+ delay(50);
+ pinMode(51, INPUT);
+
|
|
Top
|
|
|
|
|
#370138 - 14/12/2017 22:10
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14494
Loc: Canada
|
The Hijack changes (see above) were just to fix the existing bugs that we both noticed, like things stopping updating. Overall behaviour is the same as before (yesterday), except all of the output lines are now de-duplicated (included the 'Z' and 'D' lines for this). Cheers
Edited by mlord (14/12/2017 22:11)
|
|
Top
|
|
|
|
|
#370139 - 14/12/2017 22:13
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14494
Loc: Canada
|
That should still be fine, hopefully with more readable output.
|
|
Top
|
|
|
|
|
#370140 - 14/12/2017 22:17
Re: BlueGigaEmpeg
[Re: mlord]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31599
Loc: Seattle, WA
|
Thanks so much for the information about the Arduino GPIO for the reset!
I think that code might work better in this routine instead, but I'm not certain.
void QuickResetBluetooth(int resetType)
{
switch (resetType)
{
case 0:
SendBlueGigaCommand(F("RESET"));
ClearGlobalVariables();
// Reset pin code here
DisplayAndSwallowResponses(4, 500);
break;
|
|
Top
|
|
|
|
|
#370141 - 14/12/2017 22:17
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14494
Loc: Canada
|
I'm excited that you have been making progess and that you have a connection!
I'm glad that it was as simple as changing the security setting. It wasn't quite that simple. I think the hardware reset bug was preventing earlier efforts from succeeding. Once I finally figured that out, it began to work. Thanks for everything!
|
|
Top
|
|
|
|
|
#370143 - 14/12/2017 22:42
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14494
Loc: Canada
|
Again, today's Hijack fixes the first of those, and I always (on my empeg serial port) see data for the initial track after power on.
If the empeg is booted up before the Arduino is listening to the serial port, then yes, the Arduino might miss the initial track data. Easiest solution is to power the Arduino up at the same time.
But for case where the Arduino might need to be reset to get it to work, well.. yup, it will miss the track data for the currently playing track. De-dup or not.
Cheers
|
|
Top
|
|
|
|
|
#370144 - 14/12/2017 23:01
Re: BlueGigaEmpeg
[Re: mlord]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31599
Loc: Seattle, WA
|
Okay, I'll try the newest Hijack and see if it fixes the issue of the missing data on the serial port at boot up.
Generally the Arduino itself doesn't need to be reset, only the bluetooth chip seems to ever need to be reset, so this might be just fine for fixing that.
Thank you! I'll give it a shot!
|
|
Top
|
|
|
|
|
#370145 - 14/12/2017 23:04
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31599
Loc: Seattle, WA
|
What is the link to the latest Hijack with that fix? This one isn't working for me: http://rtr.ca/hijack.zImageAnd the web site still shows version 523.
|
|
Top
|
|
|
|
|
#370147 - 14/12/2017 23:42
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31599
Loc: Seattle, WA
|
Uh oh.
I implemented the reset line (connected Arduino pin 51 to the RST pin on the Betz board), and put in the reset code, and it worked for the first few minutes, but now the Betz board is completely dark and will not power up.
Even after disconnecting that reset line wire.
|
|
Top
|
|
|
|
|
#370148 - 14/12/2017 23:55
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31599
Loc: Seattle, WA
|
With the reset wire disconnected:
Voltage measured at Pololu voltage regulator: 4.96v
Voltage measured at Betz 5v pin: 4.96v
Voltage measured at Betz 3v3 pin: 183mv
When I slide the "smd_2_pole_switch" on the Betz board into the right/down position, the LED blinks steadily, indicating the chip is in sleep mode.
When I slide the switch to the left/up position, instead of waking up, the chip goes completely dark, no LED at all.
Pressing the physical reset button does not change these states.
|
|
Top
|
|
|
|
|
#370149 - 14/12/2017 23:57
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31599
Loc: Seattle, WA
|
Fully disconnect Betz board from my prototype assembly, plug into USB port: Same results.
|
|
Top
|
|
|
|
|
#370150 - 15/12/2017 00:00
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31599
Loc: Seattle, WA
|
I don't notice anything getting hot, so that's probably a hopeful sign.
|
|
Top
|
|
|
|
|
#370151 - 15/12/2017 00:05
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31599
Loc: Seattle, WA
|
On a whim, tried reconnecting the FTDI 5v jumper, didn't help.
|
|
Top
|
|
|
|
|
#370153 - 15/12/2017 01:53
Re: BlueGigaEmpeg
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31599
Loc: Seattle, WA
|
Tried a crazy idea. Attached the Lithium battery from the BlueGiga dev board to the battery pins on the Betz breakout board.
Now I get the slow blink on both switch positions, and the board gets a little warm, but I can't tell which components are the warm ones.
I'm wondering if I just need to wait for the battery to charge and then things will work?
|
|
Top
|
|
|
|
|
|
Previous Topic
Index