This week I modified the CAN codec heatshrink configuration to improve performance. This invalidated the use of the augmented run length (ARL) algorithm, as on average the compression ratio of heatshrink alone is better than the compression ratio of ARL+heatshrink. The statistics for 800 messages per block are in the image below.

We visited a 1.5km line-of-sight bike path to range test the Wi-Fi X-Bee radios.

I am behind on the configuration API and firewall given school work, the design report, and our range-testing trip. I will be writing them over spring break and then testing them when I next have access to the dev boards in FMS. These two softwares aren’t terribly complicated, so I should be able to finish them by the end of next week.

Risks

• Layout for the 2-PCB design has been completed, but has not yet been reviewed.
  • See Monday’s presentation for review.
  • 2-revision timeline remains on track to ensure any mistakes from rev. 1 can be remedied in time for final demo.
• Firmware implementation may fall behind slightly due to 18-500 design report and homework overhead.
  • More time has been allocated in the schedule by pushing back UART interface implementation, as it is closely coupled with firewall and configuration work.

Design changes

• No design changes have been made.

Updated schedule

• Pushed revision one ordering back by a few days as it has not yet been reviewed (See our Gantt chart for more details.)
• UART interface work has been moved to after spring break, to coincide better with firewall and configuration implementation tasks.

Individual updates

• Merged SPI radio API proof-of-concept
• Continued various driver cleanup efforts
• Made more concrete plans for firewall and configuration implementation
• Spent most of the week preparing the presentation and writing the design report

Schedule status

As discussed in the team status update, UART bringup has been moved to after spring break to better coincide with the firewall and configuration implementation. Other items are in danger of falling behind because of other 18-500 work (design report, homework).

Deliverables for 2019 Mar. 9

• More Wi-Fi XBee integration and testing
• Other integration tasks: codec implementation is becoming more concrete, so it will likely be added into the stack and tested soon.

This week I finished up the CAN codec. I finished implementing the augmented run length decompression algorithm and further implemented the LZSS dictionary-based compression algorithm. This reduced compression ratio to about 0.16 to 0.21, depending on the block size used. In order to minimize packet header overhead, I found that block sizes of roughly 700 are optimal. I decided to forgo the Huffman encoding implementation as it is simply a less efficient dictionary-based compression algorithm than LZSS/heatshrink.

I primarily worked on writing the design document, which unfortunately precluded my work on designing the configuration API and firewall. I will spend additional time implementing these two firmware components, as the CAN codec is tested all but integration.

My accomplishments this week:

• Investigated VNA technology for characterizing our antennae. Got reasonable (sub 2) VSWR measurements for our 2.4GHz antennae, but it is looking increasingly unlikely that we’ll be able to get directional gain measurements for our antennae. To do this, we’d need access to the anechoic chamber in REH, as well as RF signal generators. Prof. Mukherjee has been helpful in getting us access to a VNA, but it’s utility is limited to us without the other aforementioned pieces. Furthermore, the given VNA does not include 50Ohm calibration kits, so any numbers we get out of it are possibly bogus. Also, the VNA failed to pick up FM-band signals with what should have been an adequate antenna, so I’m a bit skeptical on its utility for our use case.
• Rev. 1 Review suggestions implemented and board put in for ordering. Changes made this week to the layout were largely thermal-oriented improvements, like increasing trace widths, embiggening power pours, adding via stitching, etc.

My personal deliverables for next week

• Status on getting caught up-to-speed with the state of firmware development (ft. Stan and Cameron) while waiting for the board and BOM to arrive. Sorry I didn’t get this done this past week, my bad.

Updates on last week’s deliverables:

• Firmware still not reviewed adequately, been reviewing other CMR firmware changes
• Board submitted for ordering

Individual updates

• Further work on the radio/SPI API to improve its robustness
  • The refactored interface has been tested for both receive and transmit; it is much simpler and more reliable
• Implemented interrupt-based CAN transmit mailbox synchronization to allow better coordination of the limited number of hardware CAN mailboxes (see below)
• Bridging proof-of-concept underway; initial tests will packetize, but not compress

Schedule status

UART driver bringup is falling behind, but the radio API implementation and testing is higher priority. The bringup will not take very long, so it will probably be delayed in the schedule until the configuration API becomes clearer.

Deliverables for 2019 Mar. 2

• Bridging proof-of-concept completed and tested (preferably at >1 m range)
• Integration plans for codec and configuration APIs

My accomplishments this week:

• Further touched up rev. 1 of the PCB assembly. See attached photos (not quite as up-to-date as the similar ones included in our design review):

• I’m still on schedule regarding revision 1
• Minor changes to schematics
  • Added external 1KR pull-ups on the XB reset lines, because I don’t trust us to remember to use the internal STM pull-ups
  • Added commissioning button to enable WPS mode more easily on the Wi-fi XBee
• Minor changes in the PCB design made this week:
  • Fixed some designators, rerouted a few nets, shrunk all vias to 32/16mil, added a commissioning button, added some silks to enhance user experience (labeled radios), rearranged transceiver board to map consistently left/zigbee and right/wifi, changed pour reliefs, changed transceiver board corners to curves, added a footprint, etc.
• Worked on and rehearsed for our design review
  • My total time spent on it was 6+ hrs., as I’ll be the one presenting

My personal deliverables for next week:

• Board ordered by mid-week
  • I’ll then transition into firmware writing/testing + antenna testing mode until rev. 1 gets here
• Migrate development from our tags to our trunk folder
  • Yes I’m a big dumb idiot

Updates on last week’s deliverables:

• Mounting hole positions decided on at .15″ inset from a 2×2″ square board ✓
• Range test was successful at 250-300m using our current antenna pairing, but inconclusive at 500+m; See the team’s status report for more details

This week I again worked on the CAN message compression codec. I massively refactored the code base and wrote a test framework. I implemented the trivial run length encoding algorithm and my augmented run length encoding algorithm (optional run length encoding if run length above threshold, using escape character concept from KISS link-level protocol). I’ve attached a compression comparison from my testing; the augmented run length compression is only 0.89 (838 to 749 bytes) for now. I believe Huffman encoding will improve this dramatically.

I spent the class time working with my teammates on the design presentation and fleshing out the firmware block diagram. The later was the first step of designing the CAN firewall and configuration API.

My progress is consistent with the Gantt chart, yet I am behind from the personal goal I established in last week’s status report.

Next week/tonight, I will be adding finishing touches to the augmented run length encoding (there’s a bug in the decoding), and implementing two remaining algorithms (Huffman and shrinkwrap). I’ll further design a block diagram of the firewall and config API.

Risks

• Layout for the 2-PCB design has been completed, but has not yet been reviewed.
  • See Monday’s presentation for review.
  • 2-revision timeline remains on track to ensure any mistakes can be remedied.
• Preliminary range testing with the 2.4 GHz “9” dBi dipole antennae and Wi-Fi XBees proved successful at ~250 m, but it was likely not representative of our target environment. Furthermore, longer-range testing was inconclusive.
  • Currently looking into whether or not CMU has a suitable RF chamber for our testing purposes.
  • More range testing will occur when the system has been further realized.
  • A 2.4 GHz “19” dBi directional dish antenna has been acquired (c/o Carnegie Tech Radio Club), and will be tested.
• Risks that have been resolved as of this week’s entry:
  • Partially resolved the above issues from last week, but as indicated, further mitigation is required.

Design changes

• No design changes have been made.

Updated schedule

• No updates: We’re still on schedule in terms of PCB schematic and layout, as well as firmware bringup and implementation. (See our Gantt chart for more details.)

My accomplishments this week:

• Made significant progress towards refining revision 1 of our project’s PCB (includes separation into 2 PCBs). I am on schedule w.r.t. getting revision 1 in an orderable state; I aim to order it in two week’s time, but at this rate I am likely to order it before then. Here are some sample photos on this point:
  • The layout of the assembly:
  • 
  • Individual boards:
  • 
  • 
  • Selected commit history (dellagd is me committing from one of the FMS workstations):
  • 
• Tested revision 0; SPI communication between XBee and picocom confirmed to work
• Received Xbee wi-fi modules

Deliverables for next week:

• Prototypical layout of revision 1 of the board stack-up for review next weekend+
  • Settling on mounting hole positions
• Findings from doing a range test with Xbee wi-fi modules.