Bluesaab software 5.1beta

[homerisback]

Hi,
Didn't find time to scan the code and find how and when artist & title data is collected via RN52.
I experience and have been told of an issue that appears at track change, no matter if it's a playlist track change or a manual change with SEEK buttons. RN52's extended features is set to S%,1084
From time to time, data won't update and remains on previous track's data or only artist is displayed without title. I initially thought about bad mp3 tagging but tracks are correctly displayed on phone and when switching to radio or CD then back to BlueSaab, data is fully and correctly diplayed on SID...
Could timing of data request be "wrong" (to fast maybe at track change) ? I assume update is triggered when RN52 reports a track change and no update occurs while playing a track. Could we delay a bit the data request (0.5, 1 or 2 seconds) or trigger another request after a short time of track playing ?

Another little one, is when the Bluesaab goes connectable after an engine stop. At next start, last memorized data comes back on SID (instead of "BlueSaab") until one BT connection occurs. Once again, I didn't dig into code to check if a "clear memory" happens when module goes connectable.
Thanks in advance

[Karlis]

Currently we read track metadata on RN52 status change event (GPIO2 pin goes low for 100ms). Per spec, when this happens, micro controller has to push the RN52 in CMD mode and request it's status via "Q" command. Then, once that's done, we determine that there has been a track change event and issue "AD" command to read track/artist metadata info in two different buffers. If we don't get anything in the buffers, the SID text defaults to "BlueSaab". Or if there's only "artist" or "track" we will display only that.

I guess there are two problems here: "slow" baudrate (9600) and the fact that SoftwareSerial is half-duplex. To simplify, if there's some gibberish seen on the wire, we will ignore that. And there's a lot of ambiguity, especially with longer artist/track names. This might be worked around somehow but I haven't looked into this yet and not sure if I will.

As for the second issue: yes, BlueSaab keeps info in both buffers upon switching off. Hence the next time BlueSaab is engaged, it takes a while for RN52 to realize that there's another track being played, engage the GPIO2 and signal 328 to come and fetch new track metadata. This could be worked around by flushing the buffers upon exiting CDC mode on IHU. Should be an easy fix (famous last words...).

[homerisback]

Thank you for this detailed reply. Have you guys experienced such behaviour ?

[Seth]

Yes, I've experienced it, and I believe Karlis has too. He's got some bigger fish to fry right now, trying to get v6.0, BSXM, and BSZero working

[homerisback]

Thanks I feel less alone !
His last answer let me guess that fish is much bigger, I understand