V5 & AMP on one board

[homerisback]

Hello guys,
Thinking about latest versions of BlueSAAB and AMP, I wanted to integrate the amplifier on main PCB. That requires to remove the less used parts of the module : USB Firmware update of RN52 and factory reset switch. I don't think Microchip would update it any time and the tricky factory reset procedure would so rarely be used, in my opinion.
Assuming that, I did a partial redesign of the board, moving the MIC socket and RN52 (Seth,who did lots of tests may answer "it won't work due to antenna clearances requirements" but I tried to comply with them) and integrating the THS4522 circuit. Some labels from RN52 are a bit blocked by UART pins and it would need a little extra work to move it between MCP2525 and THS4522 to free more space...
Before continuing in this way, I summit it to your expert eyes. @Karlis, Seth, Sam, feel free to tell what you think about it. I did this for fun and challenge but if it suits you, I'll be glad to continue further.

Obsolete files links removed

Cheers,
Antoine

[Seth]

Nice work, Antoine :)

You beat me to it; the next thing on my to-do list is to integrate the amp into the main pcb but with school + work, I just haven't had time.

The only thing I might be concerned about would be how close the rn52 is to the bottom right mounting hole; I feel like the rn52 edge might be sitting on the boss when installed.

Other than some personal preferences when routing, it looks like that board should work fine. Did you have any made?

Seth

[homerisback]

Thanks,

I share your concern about RN52 and the mounting hole... I tried to keep it as far as possible without too much modification to your original layout, maybe not far enough by now.
I hadn't any made from now as I shared my work "out of the box" and OSH Park fab delays are quite long to France ;) Nevertheless, I think I'll give a try with a set of 3 PCBs when they are more optimized.

Once again, I'm open to comments on this work and if you have suggestions to improve it, I'd be happy to look at them. Actually, I don't like the number of vias I added on the PCB, it's too "heavy"...
Stay tuned ;)

[sbt]

homerisback wrote

Once again, I'm open to comments on this work and if you have suggestions to improve it, I'd be happy to look at them. Actually, I don't like the number of vias I added on the PCB, it's too "heavy"...
Stay tuned ;)

Antoine,

Nice start; I've been pushing for integrated amp ever since it became clear every board should have one. I was really tempted to have a go myself, but no time...

To free up some PCB space, here are some suggestions:

1) You can hang the RN52 antenna area over the edge of the main board. In fact, according to the data sheet, this is preferred. This will free up some space on the board. I'd also notch the area where the antenna is. I don't think there's enough room in the box for it to completely clear the standard board size;
2) As well as the RN52_Firmware header, the FTDI 6 pin header and 4 pin UART headers are not strictly needed;
3) You can leave out the component value labels and LED colours. Only the IDs are really needed to build the board, since the schematic is authoritative;
4) Seth and Karlis may disagree with this, but I don't believe the 555 and associated components introduced in v5.1 are needed. There was a software bug that prevented the ATMEGA's in built watchdog from working correctly, but this has been fixed (since v4.0 release) and the built-in watchdog should be able to cope with any issues. I've not had a crash/hang on my v5.0 since the fix went in. I'm hoping for a 4.1 release to get this into the 'wild' ASAP.

You can spend a lot of time trying to reduce vias, but that's not as important in my view as getting good noise/RF conformance. I'd be trying to maximise spacing between components, and potential reflection points in data paths. Also, even though they're balanced, I'd be trying to keep the analogue audio paths as far away from the CAN/serial lines as possible. To ensure you benefit from the balancing, keep the + and - lines of each channel as close to each other as possible.

Good luck.

Cheers,
Sam.

[homerisback]

Many thanks Sam,

sbt wrote

1) You can hang the RN52 antenna area over the edge of the main board. In fact, according to the data sheet, this is preferred. This will free up some space on the board. I'd also notch the area where the antenna is. I don't think there's enough room in the box for it to completely clear the standard board size;

I thought about doing this when reading RN52's datasheet. There is enough room in the box, but it may be hard to insert the module with the protruding antenna so notching the board might be an easier way to go.

sbt wrote

3) You can leave out the component value labels and LED colours. Only the IDs are really needed to build the board, since the schematic is authoritative;

I agree with that when labels aren't helpful for soldering or programming/updating the module.

sbt wrote

4) Seth and Karlis may disagree with this, but I don't believe the 555 and associated components introduced in v5.1 are needed.

I remember an answer from Seth who was also doubtful about the 555 stuff need.

So, I keep going this way and improve the layout following your suggestions.
Saabist regards,
Antoine

[sbt]

homerisback wrote

There is enough room in the box, but it may be hard to insert the module with the protruding antenna so notching the board might be an easier way to go.

That's true if the RN52 is on the opposite side to the CDC connector. It would be possible to place it on one of the sides perpendicular to the CDC connector so that it doesn't foul the lid screw 'pegs' on the way in; it would have to be towards the middle of one of the sides. Close to where it is on Seth's current design is probably viable. When I was thinking about this change, I expected moving the RN52 towards the bottom and to the side to overhang, and removing the amp board header would make enough space on the back of the PCB for the amp IC and resistors.

Cheers,
Sam.

[Seth]

On my todo list (when I get time; prob not until May with my school schedule) is:
- move amp pcb to main pcb (we can use Antoine's design, maybe tweak it some)
- Make CAN1 and CAN2 leds into one bicolor LED; red/yellow
- Make BT1 and BT2 into one bicolor LED; red/blue
- Make RX and TX into one bicolor LED; red/green
- Remove RN52 USB firmware update connector
- Fix RN52 reset button (or remove all together)

And one major thing I'll probably be looking into is redesigning the entire board to use a new microprocessor with CAN capabilities built in, among other additions (more UARTs, faster speed, etc).

[Karlis]

sbt wrote

2) As well as the RN52_Firmware header, the FTDI 6 pin header and 4 pin UART headers are not strictly needed;

I'd say these two headers have to stay. UART is our only way to talk to RN52 without 328 inline or do FW updates in the future (if any). FTDI could stay as a "direct" access to 328 when we decide to remove software updates via USB and move on to Bluetooth SPP.

[Karlis]

And like Seth mentioned earlier, we're exploring a possibility to have a 2-in-1 solution for main uC and CAN controller. Turns out majority of CAN nodes in the field nowadays use this sort of approach. This way we could get rid of the "bulky" MCP2515 thus freeing up some real estate. :)

[homerisback]

I've been working on it today and I didn't need to remove UART and FTDI pins (didn't wanted to do so either). A few airwires remain to be routed, hopefully I'd have something good to show you soon.
I had a look at Mouser about the 2-color LED but the color couples Seth wants didn't show up when asking for Kingsbright SMD, so I kept the actual LEDs on layout.

[homerisback]

Here is a fresh new layout, I followed the easiest part of todo list :
- removing 555 & killswitch circuit
- removing RN52 firmware update circuit
- removing AMP pins
- moving MIC jack
- moving RN52 according to datasheet's recommandations
- integrating AMP circuit and keep audio lines away from CAN buses
- renaming capacitors & resistors on amp circuit.

Obsolete files link removed, see below for update

I didn't achieve to integrate dual color LEDs cause none of the Kingsbright LED available on Mouser suits Seth's wishes and didn't find library for them... probably Eagle's functionality I handle the worst

[Seth]

Not bad. There are probably some more efficient ways to route some of the bypass capacitors and such around the amp pcb; the original amp was so small it was hard to fit everything "nicely" and still get them to be optimal placement. With all the extra room here, I'd like to clean that stuff up. Also, I would go over all the labels and whatnot so the silkscreen is legible.

I haven't measured the antenna size, but I would think that it should fit ok on the side there. Although I never had a single issue with the antenna flush with the edge of the pcb...

I found several bi-color leds on Mouser, but haven't actually settled on any. I think they would need to be common-anode type (and ideally all the same shape/brand/size).

So maybe if I get time (ha, what's that), I could do some small tweaks and make it 5.21 :)

[homerisback]

Thanks for your reply, feel free to improve it...when you have time ;)

[homerisback]

I agree with you, Seth, about RN52 antenna's position : I never had any issue with its original position and I think it was a wise choice to avoid any damage to it or the whole chip ;)

Having time, I improved my previous layout to keep + and - lines of balanced audio signals the closest possible along their path by routing one signal on each side of PCB, as it appears to be a strong recommandation for balanced audio signals.
I used round angles as it is also recommended to avoid signal reflexion in 90° angles or even in octogonal routes. Anyway, we're not doing professional rated HiFi, aren't we ?
Did little routing improvements and cosmetic "cleaning" of the layout. I kept many values as well on silkscreen, because without them my previous bunch of three modules wouldn't have worked as Mouser BOM wasn't consistent and had wrong resistors. My mistake, I was too much confident in it.
Named it 5.3 but it could replace the former 5.2 if you prefer, as it isn't a big revision and maybe it will never see the sun...

[Seth]

Looks good to me! Personally, I'm not a fan of round traces. But that's just me; they should work just fine!
And no, we're not doing anything high speed so the traces don't really matter much. I was taught never to route 90deg angles, so I usually always stick to 45deg. Again, personal preference.

Only thing that needs "fixed" is the BlueSaab 5.2 silkscreen --> 5.3 :)
Oh, and and "issue" with OSHpark/the eagle layers...the stupid value layer never gets silkscreened, so I always have to edit EVERY SINGLE ITEM so that the value for the component is on the name layer, not the value layer so we can get the values printed as well as the name. Not 100% necessary, but as you said, the Mouser BOM isn't 100% because Mouser is RETARDED with their project lists parameters...

I would ideally like to make the LEDs into the dual footprints but that's not required; just something on my todo list.

And when Karlis gets time, we'll soon be going to bluetooth software uploads so we can get rid of the expensive FTDI chip + parts & usb socket.

[homerisback]

You're right, I saw the 5.2 instead of 5.3 when uploading on OSH park :-P
Thanks for the issue about layers, will double check that...

I'd really like to implement dual color LEDs but I can't find any eagle library to do it and I wouldn't choose wrong LEDs. Could we use mouser's Kingbright ones even if they aren't the colors you mentioned ?
I found the Kingbright's datasheet and tried to make my own library with it but didn't really succeed till now. Keep going !

That's nice to read : bluetooth software uploads ! Would it be possible ?
Eventually, it will take place on half a credit card surface when we remove all the extra stuff !! :-D

EDIT : Added an extra feature on board... absolutely useless 

[Seth]

If I can get 30min-1hr or whatever, I could create a library for the dual LEDs. But it's not super important. Or we could just leave them the way they are. No biggie.

Bluetooth software uploads are quite possible. BUT. Karlis said something about needing a 2nd UART port in order for this to work and not conflict with the current UART comms. So it might not be possible with the current uC, which is part of the reason I'm going to start looking at the ST Micro uC line, with built in CAN and faster speeds, and etc.

[homerisback]

I commited a library with 0805 dual color LEDs before checking on PCB we're using 1206 LEDs... Going back to work !
Anyway, in my opinion, I like separated LEDs for each signal. That's my personal preference, like octogonal tracks vs round tracks

Latest update of 5.3 board, with its extra and totally useless feature. Moved a few components (resistors, capacitors and U3) on board and from one side to the other, to make more room between CAN comms & audio signals. Added ground planes. Normalized labels.

I have one question about Atmega328, is it that necessary to have an automotive certified chip ? The price of it is 3 times another "standard" one.

[sbt]

homerisback wrote

Anyway, in my opinion, I like separated LEDs for each signal. That's my personal preference, like octogonal tracks vs round tracks

Agreed; separate LEDs at least means you don't need a key to understand which is e.g. RX or TX. For BT leds though, you still need to know what the functions are.

homerisback wrote

Latest update of 5.3 board, with its extra and totally useless feature. Moved a few components (resistors, capacitors and U3) on board and from one side to the other, to make more room between CAN comms & audio signals. Added ground planes. Normalized labels.

Nice. Small quibble, but with the removal of the 555 (effectively a revert to 5.0 as a starting point), I wonder if it's preferable to reinstate the via array running down the left side that Seth included in 5.0. I believe this was for heat/noise dissipation.

homerisback wrote

I have one question about Atmega328, is it that necessary to have an automotive certified chip ? The price of it is 3 times another "standard" one.

I believe the principle behind "automotive" parts is resilience in the environment, including noise, heat and vibration, such as that found in the engine bay. You could argue (assuming the BlueSaab is to be installed in the passenger compartment) that this requirement is excessive. Care to try out a regular ATMEGA and share what happens?

Cheers,
Sam.

[Karlis]

With "automotive" I as thinking of a two-in-one solution for uC and CAN controller. So there's only one chip that does both. We could retire MCP2515 in that case and save tons of space by doing so.

I would agree that by definition it means better tolerances to heat, humidity, vibrations and whatnot, but my idea was more of a 2:1 solution. :)