Individual updates

• Fixed the codec corruption bug (wrong index used when placing received data into a buffer, leading to random data being decompressed)
• Performed further testing for compressed streaming
  • The link remains robust, but “stuttering” due to dropped packets causes large “silent periods”/lag while TCP re-establishes
  • UDP will likely be used instead, as we do not guarantee ordering.
• Assisted with other team-wide firmware integration tasks.

Schedule status

My deliverables remain on schedule.

Deliverables for 2019 Apr. 6

• Firewall integration
• UART configuration integration
  • Potentially CAN configuration support as well

I spent the last week working on responding to the configuration system pull request feedback and implementing the firewall. I intended to finish the UART system and integrate it into the config system, but ran into some problems with the firewall.

I initially naively implemented the firewall by appending to an array of firewall entry structs, requiring linear lookup time. Under Zach’s suggestion, I reimplemented it using bitfields to prove constant lookup time. This is important as the firewall needs to be run on every CAN message.

The issue with the config flash system preventing reprogramming the TOM without a full chip erase became a problem in debugging the firewall. I tested the config system by reading from a flash sector, incrementing the value, and writing it back throughout the entire sector. I would reset the board multiple times, and check that the incremented value was correct by using the ST-Link Utility to analyze the flash. However, between subsequent debug executions, the TrueStudio memory viewer shows incorrect information. I ultimately verified the firewall by using debug flags.

I also had a few silly bugs in the config API that manifested when implementing the firewall, involving pointer typedefs and incrementing order of operations.

Next week, I’ll finish the UART integration and XBee switching.

Risks

• Packets dropping over the TCP link (even over a short distance) affects link stability quite significantly. The link will often be interrupted for a few seconds when packets drop.
  • We will likely switch to UDP, as we do not provide strict ordering.
  • We also have a more exotic idea in the works: UDP enables us to move
• Rev. 2 changes are still in progress.
  • The revision will be laid out by Monday, 1 April.
  • It will be reviewed/ordered shortly after.
• Range testing still to be done.
  • Testing will occur soon in the FMS breezeway and parking lot.
  • Additional testing will likely occur at PittRace; the team plans on heading there for track testing in a few weeks.

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 implementation. (See our Gantt chart for more details.)

Individual updates

• Completed various bugfixes for the STM32 drivers.
  • This also included an upgrade to the latest HAL version, as the previous one was several years out-of-date.
• Brought up the UART drivers.
  • They have been tested successfully on a development board, and should work similarly on a TOM (further testing upcoming).
• Integrated the compression library Cameron selected and tuned (heatshrink, based on the LZSS dictionary algorithm).
  • Both encoding and decoding has been tested successfully on the TOMs.
• Assembled, reworked, and tested the Rev. 1 board pair.
  • See this week’s Team Status for more details.

Schedule status

My deliverables remain on schedule; they have been adjusted to account for the actual completion dates of various tasks from the past two weeks.

Deliverables for 2019 Mar. 30

• Further debugging is required on the Rev. 1 board pair.
• More firmware debugging is necessary, as some bugs may be present that are causing the communication link to be unreliable.
• Configuration interface design will begin.

Rev. 1 works!

A single Rev. 1 board pair (MCU and transceiver) was assembled and tested; they communicate successfully with Rev. 0. This marks the first time we have successfully bridged two CAN buses!

Pictured above is our test setup. The Rev. 1 pair is on the far left and attached to a PC using a CAN-USB adapter. The Rev. 0 board (far right) is attached to a separate laptop PC using another CAN-USB adapter.

Risks

• The ribbon connectors on the Rev. 1 boards are unfortunately facing the wrong direction. The cable can still be attached, but it must enter the connector from the opposite side, causing interference on the transceiver board.
  • Since the cable only interferes with one transceiver “slot,” the other one is temporarily used instead. This is not a significant concern, as we only use one radio at a time anyway.
  • A future revision will re-orient the connectors.
• The ribbon connector is intended to be used with the cable’s contacts facing the board (“downwards”), but the pin layout requires the cable’s contacts to face away from the board (“upwards”).
  • The connector still appears to work with the contacts facing away from the board; we will continue to use it this way for now in order to proceed with debugging.
  • A future revision will either use a reverse-direction ribbon cable, or a “top-facing” connector on one side.
• Timeline is getting somewhat stressed.
  • Core features appear to remain on track, but we will continue to monitor our progress in the coming weeks, especially as testing reveals potential flaws.
  • Depending on how much slack is remaining, the Ground Control UI’s functionality may ultimately be limited to TOM configuration, as it is the most critical feature.
• “Unknown unknown”: Either the inaction of XB1 attention line or the “full-duplex” operation of our SPI drivers is preventing two-way communication back to Rev. 1.
  • Debugging will continue this weekend and into next week.
• Range testing still to be done.
  • Testing will occur soon in the FMS breezeway and parking lot.
  • Additional testing will likely occur at PittRace; the team plans on heading there for track testing in a few weeks.

Design changes

• No design changes have been made.

Updated schedule

• Rev. 1 confirmed to be functional, so we’re fast tracking the next revision for ordering.
• Other schedule tasks have been adjusted to reflect actual task completion dates; dependencies have been shifted accordingly.

My accomplishments this week:

• • Revision 1. jointly reflowed with Stan
  • Relevant PR’s reviewed and merged for SPI transmission, heatshrink interface
  • Got Cameron up-to-speed on testing his code on our toolchain (previously just running tests standalone)
  • Reworded Rev. 1, tested, electrically solid
  • Made a list of changes for Rev. 2 (will actually need to happen now, I definitely frigged some things up)
    • Change both ribbons to slide connectors
    • Shorten header to make sure it clears
    • Order shorter ribbon (can’t cut to length, I’m dumb)
    • Improve pitching on breakout pins (embiggen)
    • Remove/move poorly placed designators
    • Fix 0201 Caps in BOM
    • Add connector, headers to BOM
    • Expand transceiver board ground pour to mounting hole
    • Consider moving power delivery off ribbon
    • Move resistor
    • Add reset caps to gnd
    • Move connector back from the lip if possible
    • Renumber designators across boards

My personal deliverables for next week:

• A revised Rev. 1 (Rev. 2)
• Rev. 2 ordered by end-of-week
• Investigation into board mount/spacers/enclosure

Updates on last week’s deliverables:

• I’ve reviewed a decent chunk of the codebase, but I still need to get more intimately involved with Cameron’s interfaces and the UART driver
• See above for board status

I spent Spring break familiarizing myself with the existing STM32 firmware, development tools, and designing the configuration system and firewall.

I spent last week working on the configuration system implementation and UART API. I passed off the UART API to Stan to perfect the DMA calls as he had experience with that in the SPI API. The STM32 hardware abstraction library (HAL) UART receive function doesn’t have the ability to receive an arbitrary number of bytes; this has to be implemented using DMA and UART idle interrupts. The config system itself is rather simple, simply writing and retrieving data from the MCU’s flash memory.

However, I ran into some trouble with the ST IDE, TrueStudio. After erasing or writing the flash memory with config data, the IDE fails to reprogram the development board. However, the configuration system continues to operate correctly throughout board reset. I discovered the only way to successfully reprogram the board is to completely erase the board’s flash using the ST-Link Utility software. I researched online, and discovered several possible explanations/remedies, although nobody has had the same problem as me: there is a bug with the TrueStudio flash utility, the TrueStudio flash process performs a checksum on the entire flash memory that thus fails after a flash write of configuration data (which I tested as not true, as simply erasing a flash sector that was already erased and untouched still prevented reprogramming), and the hardware abstraction library flash function sets a flash lock bit. Further, I found that writing to flash sector 2 allowed the board to be reprogrammed without error, however this overwrote part of a symbol table thus causing FreeRTOS to crash. In order to verify that my code is not simply incorrect, and that the problem does indeed lie with MCU/TrueStudio configuration, I tested the provided STM32F413 example flash program, which simply erases a few sectors (2 and 3), writes to them, reads from them, and verifies the writes were successful. This caused the same problem as the TOM firmware. I’ve decided it’s better to continue developing the firewall and live with the minor inconvenience of having to erase the flash before reprogramming. I’ll have my teammates take a look whenever they have some down time, and continue to work on it myself. One next step to confirm that the problem lies with TrueStudio, is to program the board using the STM32Programmer software. I have yet to do this as the software was too buggy on Ubuntu 18.10 to move past the start page.

My plan is to double check the config system, implement the firewall, and send a pull request for both to my teammates, by Monday night. Following this, I’ll integrate the UART API into the config system and firewall. If time permits, I’d also like to update the config system to easily switch between the Zigbee XBee and Wi-Fi XBee.

My accomplishments this week:

• Most of the week spent preparing for design review and writing our report
• Got rev. 1 mostly ready for ordering. Changelog as follows:
  • Added silks
  • Rerouted some of the ribbon connections
  • Increased the size of tracks on some nets
  • Repoured power plane to use direct contact (no relief)
  • Moved some traces around to reduce impedance on MCU power lines
  • 

My personal deliverables for next week:

• Board actually ordered
• 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

Updates on last week’s deliverables:

• Version control migration done
• Board pending review as of Friday (2 days behind schedule, Gantt chart has been pushed back into slack slightly)

Risks

• We tested the Wi-Fi XBee range at a 1 km line-of-sight stretch of the Great Allegheny Passage in McKeesport. The Wi-Fi range was significantly shorter than predicted using the 9dBi antennas, at approximately 200m. Additionally, the directional 19 dBi antenna tests were inconclusive.
  • We plan to recreate these tests in the FMS breezeway and parking lot.

Design changes

• No design changes have been made.

Updated schedule

• No schedule changes have occurred.

Individual updates

• Wi-Fi proof-of-concept has been implemented and tested.
• Bidirectional uncompressed CAN streaming works well (plug-and-play).
• More robust integration and preparation for rev. 1 is necessary.

Schedule status

My deliverables remain on schedule.

Deliverables for 2019 Mar. 16

• Nothing scheduled, as it is spring break and I am out of town.