It enters CDC mode, but doesn't show up in BlueTooth

[Pilkerton]

So my freshly assembled unit appears to be communicating with the IHU (lots of activity on the BT1/BT2 LEDs, CD1 shows up on the SID), but the AR52 does not advertise itself on Bluetooth. Could I have clobbered the AR52 somehow?

I grabbed the source from the 'master' branch a couple of days ago (the check-in comment was: "Adding PWREN pin handler. This 'shouldn't affect all the modules < v3.3"). But as I write this, I now notice there's been another check-in since then, so now I'm thinking I should just try the official SAAB-CDC release v2.1…

[Seth]

The BT1/BT2 lights are for bluetooth status, not IHU status. But having said that, if your SID says "CD PLAY 01", then the module is talking to the car ok, and the radio sees the module. So the issue now is bluetooth.

The BT1/BT2 lights flash alternately when it's in discovery mode. At this point you should be able to use your phone and scan for available devices (unless you've already connected to it in the past) and it should show up, most likely as "RNXX-XXXX" or something.

The RN52 is kind of a pita to solder...so i would def check there first. make sure each connection is good, clean, and no shorts.

Post back what your BT1/2 leds are doing; that will be a good start in troubleshooting.

[Pilkerton]

se4587 wrote

The RN52 is kind of a pita to solder...so i would def check there first. make sure each connection is good, clean, and no shorts.

Yep, no kidding. There's a line in the RN52 product brief that says, "Castellated SMT pads for easy and reliable PCB mounting" LOL

The top side was a piece of cake in comparison - my first ever experience doing SMT (I used a stencil + solder paste + hot air). But for the bottom side RN52, I applied too much solder paste and created some bridges. I cleared the shorts, but the device was not discoverable. I removed the RN52, cleaned the pads and soldered it back in, but still the same behavior.

Since comms with the IHU are happening, can I assume that the Atmega flashed successfully? I did not follow the recommended procedure, but instead flashed the blank Atmega in an Arduino board connected via ICP to a USBasp.

[Seth]

Yeah, the 328 should be fine since the car can see it and it's not dropping out.

I'm wondering if the rn52 is set to the "wrong" baud rate for comms; I can't remember if it uses 9600 or 115200, but the new software on 328 uses 9600 because it had more reliability.

I think you could try to short the 9600_baud pins on the bottom of the pcb and see if that works...that's kind of a back door to get to the rn52. Ideally that setting can be changed in the rn52, but it's a catch22; can't change the setting because you can't talk to it and you can't talk to it because the settings need changed!

So one way around that (If this is the problem), is change the 328 code to talk to it at 115200, upload it, change the rn52 settings, (which will present gibberish in the com window cuz now the baud rate is "wrong"), then change the 328 code back to 9600 and upload it again. I *think* that will work; I had to do something similar myself when upgrading the software. 

On May 9, 2016, at 13:03, Pilkerton [via BlueSaab Forum] <[hidden email]> wrote:

se4587 wrote

The RN52 is kind of a pita to solder...so i would def check there first. make sure each connection is good, clean, and no shorts.

Yep, no kidding. There's a line in the RN52 product brief that says, "Castellated SMT pads for easy and reliable PCB mounting" LOL

The top side was a piece of cake in comparison - my first ever experience doing SMT (I used a stencil + solder paste + hot air). But for the bottom side RN52, I applied too much solder paste and created some bridges. I cleared the shorts, but the device was not discoverable. I removed the RN52, cleaned the pads and soldered it back in, but still the same behavior.

Since comms with the IHU are happening, can I assume that the Atmega flashed successfully? I did not follow the recommended procedure, but instead flashed the blank Atmega in an Arduino board connected via ICP to a USBasp.

---

If you reply to this email, your message will be added to the discussion below:

http://bluesaab-forum.2349123.n4.nabble.com/It-enters-CDC-mode-but-doesn-t-show-up-in-BlueTooth-tp331p334.html

To start a new topic under Hardware, email [hidden email]
To unsubscribe from Hardware, click here.
NAML

[Karlis]

Let's look at what RN52 is actually doing. When you power up the module, which of the LEDs light up and in what fashion? Is it the blue one only blinking with ~1sec interval? If so, the module is in "connectable" state (which means it's looking for a "known" device). If both BT1 and BT2 LEDs are flashing alternatively, that means the RN52 is in "discoverable" mode. That means it's ready to pair and should broadcast itself (you should see it in Bluetooth settings of your phone).

As Seth mentioned earlier, there might be a mismatch of serial baudrates. By default (factory setting) RN52 is configured to accept comms @ 115200bps. After a lot of testing we determined that this baudrate is causing issues (curved signals as opposed to nice squared ones). So the baudrate setting on RN52 has to be changed to 9600bps. One way of doing this is to short two pins on the bottom of the PCB. Once that is done, you should be able to upload the latest v2.1 code to the board, switch over to CDC mode on IHU and by holding SEEK+ button on IHU push the RN52 into discoverable mode.

Hope this helps.

[homerisback]

Hi guys,

While struggling to communicate in CMD mode with RN52's, I finally went into the hardware way and jumpered GPIO7 and GND to force 9600 baud comms.
Meanwhile, I checked on Github the version available and downloaded the May 2016 revision of CDC v2.1
I uploaded it into the my left two 328's and........ RN52 refused to start, on both modules, since 328 is on the BlueSAAB module, when 328 is removed from the board, RN52 starts properly with external power (i.e. FTDI cable)
From there, I checked the changes made in the code and removed the PWREN related lines and reverted to previous way of starting RN52 chip => it works flawlessly in car. So, from now, I can say that the PWREN mod affects the PCBs < v3.3

Could I suggest to revert back to previous v2.1 - March 2016 for PCB < 3.3 ? This should solve Pilkerton's issue.

I noticed bluetooth odd behaviour with that version as well, I'll report this in software section.

[Pilkerton]

Yes, the BT1 and BT2 LEDs were flashing alternatively, indicating the RN52 was supposedly in "discoverable" mode and ready to pair. However, it never broadcast itself. After trying various things (including manually putting it into "discoverable" mode by sending it the command over serial) and still being unable to get it to broadcast, I gave up and replaced it with a fresh RN-52 from eBay which worked a treat. After using RN52-BT-PRG to adjust the default volume levels and then flashing with v3.0 firmware, everything is functional.

However, I now have the problem of the hideous noise on one channel while the engine is running. The noise is accompanied by a higher-pitched, RPM-related whine that's lower in volume. Yesterday (before I adjusted the default volume levels), it was on the right channel. Today, it's on the left channel. It's OK for listening if I crank the balance to the good channel.

Karlis, I think you mentioned in another post to check the IHU for corroded ground connections. So I would just pull the IHU from the console and inspect the connectors around back? This is a 9-3 2000 with the CDC connector located near the antenna.

[Seth]

I would also check for good connections on the cdc connector (maybe on back of ihu?)...but it does sound like a poor ground somewhere. Might also wanna check for the body grounds near the ihu, and trunk. 

On May 21, 2016, at 22:42, Pilkerton [via BlueSaab Forum] <[hidden email]> wrote:

Yes, the BT1 and BT2 LEDs were flashing alternatively, indicating the RN52 was supposedly in "discoverable" mode and ready to pair. However, it never broadcast itself. After trying various things (including manually putting it into "discoverable" mode by sending it the command over serial) and still being unable to get it to broadcast, I gave up and replaced it with a fresh RN-52 from eBay which worked a treat. After using RN52-BT-PRG to adjust the default volume levels and then flashing with v3.0 firmware, everything is functional.

However, I now have the problem of the hideous noise on one channel while the engine is running. The noise is accompanied by a higher-pitched, RPM-related whine that's lower in volume. Yesterday (before I adjusted the default volume levels), it was on the right channel. Today, it's on the left channel. It's OK for listening if I crank the balance to the good channel.

Karlis, I think you mentioned in another post to check the IHU for corroded ground connections. So I would just pull the IHU from the console and inspect the connectors around back? This is a 9-3 2000 with the CDC connector located near the antenna.

---

If you reply to this email, your message will be added to the discussion below:

http://bluesaab-forum.2349123.n4.nabble.com/It-enters-CDC-mode-but-doesn-t-show-up-in-BlueTooth-tp331p409.html

To start a new topic under Hardware, email [hidden email]
To unsubscribe from Hardware, click here.
NAML

[Karlis]

First place I would look for the culprit, would be the GND connection of the CDC wiring harness behind the upholstery in the trunk. It is possible that in some certain climate conditions that connection accumulates corrosion and needs to be cleaned up.

Second place I'd look into is behind the actual IHU. I'd take it out and jiggle the wires a bit to see if that makes a difference. If it does, then there's some bad connection in some wire. Given the fact that those connections are "clamp" like, it is possible that some of them are loose and give a bad contact.

Third (unlikely) and again climate-related is a bad connection at the amp. But since this issue (as I understand it) only shows up only when IHU is in CDC mode, it is unlikely to be the problem.