Skip to content
This repository has been archived by the owner on Dec 16, 2022. It is now read-only.

Hardware History

Jump to bottom
Jason Kridner edited this page Oct 9, 2020 · 4 revisions

This will be in reverse chronological order

Rev C

Concept

Rev C is a feature fix rev (see Rev B issues), along with Seeed taking over the layout. They will also focus on DfM and integration with an enclosure they designed, in preparation for doing high volume production. The design will still be laid out in KiCad.

Issues and findings

  • USB connection seems to only work in a single orientation.

Features to validate

  • USB UART connection over MSP430 to CC1352
  • Ability to reset and flash MSP430
  • Ability to reset and flash CC1352
  • Each sensor
  • Battery charger
  • Each LED
  • Each connection on mikroBUS headers
  • 2.4GHz BLE and 802.15.4 communication
  • Sub-1G 802.15.4 communication
  • Reset button
  • User button and ability to enter flash mode
  • TAG-Connect JTAG debug and production flashing

Rev B

Concept

Revision B of the BeagleConnect was much smaller, and by definition, needed to be simpler. Due to the size restrictions, we flipped the second Click header to be on the back side of the board. This will make a stacked set of boards, but should minimize the overall footprint of the design.

We also started engaging with Seeed studio to pull in components that will be available in the China ecosystem at a (dramatically) lower cost. Here is a summary of the changes between Rev B and Rev A:

  • Smaller overall footprint
    • The net effect is that the second click header flipped to the back of the board
  • No 5V boost generation
    • This was listed as not critical for user operation, as less than 30% of Click boards use 5V
    • It is still possible to power the 5V rail if USB is plugged in
  • No on-board battery, though the JST header remains
  • The RF section has far fewer passives and is now using a balun to go from differential to single ended.
  • MSP43055xx family will do the USB handling and firmware loading.
  • SPI flash memory hooked to both the MSP430, as well as the cc1352r
  • Added (linear)battery charging
  • Added 3 default sensors to the board so the out-of-the-box experience for a user would start pumping data, regardless of whether they have a click board to plug in. Due to the restricted number of remaining pins on the cc1352r, we will OR the interrupt lines together.
    • Light sensor
    • Temperature/humidity
    • Accelerometer
  • Programming header is now only via the tag-connect, which work on opposite sides of the board to program the MSP430 and the cc1352r.

Issues and findings

  • TVS diodes were the wrong size, left those off the prototype
  • The programming pin routing to the MSP430 was incorrect. It followed the ARM programming and did not properly connect to the MSP430 style of programming (SBW).
  • The soldermask around the center pad of the MSP430 was prone to peel up during any amount of rework (which happened often). This caused unintentional shorts between micro pins and the center ground pad.
  • The serial lines were routed to the wrong pins on the MSP430, these only can be used for bootloading, not for actually talking over serial. Those need to change in the next rev.
  • The assigned pins on the cc1352r needed to be shuffled around, as well, due to bootloading requirements on the cc1352r.
  • During testing, we were not able to validate the signal output of the 868/915 MHz radio by communicating between boards using the default Contiki sketch. After amplifying the output of the 868 output, we were able to see that the device is sending packets successfully, so the front end (balun, etc) was verified, though the impedance of the trace could be improved.
  • The initially spec'd MSP430F5500 was too small for code execution, we switched to the F5503 for prototyping. Production will require at least the F5501 part. Larger will give more flexibility in the future, though there will be a cost to doing so.
  • The fuses on board are probably not required in production, especially F801. There is a resettable fuse that goes from the USB 5V rail direct to the 5V output on the Click header. It might make sense to keep that to prodtect the user.
  • There is not a good way to program the MSP430 from the field, nor bootload the cc1352r. This will need to be fixed in rev C.

Rev A

Concept

Revision A of the BeagleConnect (BC), formerly BeagleDust started in June of 2019. We decided to integrate a battery directly into the unit. To save size, it was a single AA battery, though we considered other options like two AAAA batteries. Li-Ion was out of the question because of shipping restrictions. The overall design would use the cc1352r, which is still being used as of Rev C, and would need to accommodate two Click headers. Due to the various other inputs to the design (USB, 2mm JST for a sold-separately li-ion battery), the circuit had a range of boost, buck and ideal diode converters to allow for each input to power the device, while not interfering with the other power inputs. The boost regulator would also allow powering the 5V output to the Click header, which is part of the standard.

Issues and findings

  • Battery pads were not sized properly for a AAA battery
  • The pins we chose to hook the buttons to needed to be configured for bootloader mode
  • The board was populated with the more expensive cc1352p, which had no discernable effect on the operation
  • The RF front end (caps, inductors) had far too many components to be practical. This was copied from the Launchpad design.
  • Power was being routed into the board via a diode, giving a false low reading. This was a bench error, not an actual error in the design.
  • The side mount buttons locked up after assembly sometimes. This may have been due to high reflow temps. These will not be used on future designs, regardless.
Clone this wiki locally