Feat: API Parsing and Radio Diagnostics #106
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Sunlink Pull Request Description
API Mode Parsing and Radio diagnostics. All Work Credited to Evan Owens. PR separate created by me for testing purposes.
Steps Before Merge:
My changes are as follows:
A. API Mode Parsing Support
Changed linked_telemetry to split chunks based off a regex that identifies different api packets.
Modified main.py to identify API packets and then split them into individual messages, storing those messages in a list
Parse requests resemble Aarjav's latest changes, with main.py now returning a list of parse responses
Created API_Frame python file, which contains functions that main.py uses to break down API Frames. These functions include:
Split_API_Packet -> Loops through Each packet, and Grabs 24 byte long can messages into a list, appends a Type byte in front of each message (Always CAN, but can append different types of bytes when we bring back IMU and GPS)
Parse API Packet - identifies the type of API packet, whether it is a 0x90 Receive Frame, or an AT Command (0x88, 0x97). If packet is a receive frame, it is passed to split_API_Packet.If packet is a AT command, the corresponding Type Byte is appended onto the front, and it is returned to main.py.
Create_Message now creates messages based off the first byte in each message, which is the type byte. As mentioned above, these type bytes are added by the Parse API Packet Function (while I have also added code in respective areas to add type bytes to randomizer functions, and CAN messages from the PCAN.) These means that non api randomizers create parse-able messages.
Created randomizer functions for API Frames, AT Local commands, and AT Remote commands. The API Frame randomizer utilizes CAN, GPS, and IMU randomizers to build the frame.
Added Data classes for AT Local and AT Remote Messages.
B. AT Command Data Collection
Added Data classes for AT Local and AT Remote Messages.
Created AT Diagnostic Command Function/Thread which transmits Diagnostic AT commands on an interval. So far, we transmit RSSI (DB), GOOD Packets Received (GD), and Packets with Errors Received (ER). We can expand this list
Slightly Restructured linked telemetry, and moved where the serial port is open in order to pass ser as a parameter to the Diagnostic At Command. This means that args.randomizer/can/else statement which selects the message source is slightly different.
Implemented thread locking, and event scheduling to coordinate access over the serial port. Right now it works as follows:
a. thread for Diagnostic At Commands (write thread) is created. Enters its forever loop. A forever loop for reading serial is also entered on the main thread but stops on event.wait() function call.
b. write thread takes control of serial thread lock, and transmits AT commands. A Flag is then set that indicates that the AT commands have recently been transmitted.
c. write thread checks flag, and if it has recently transmitted commands, it gives up lock, and sets an event allowing the main thread to start reading the serial stream. Write thread then goes to sleep. Read thread will continue reading the stream until the write thread wakes up again.
d. When the write thread wakes up, it clears the read event, stopping serial reading, and allowing the write thread to take over the write lock.
e. The last steps repeat over and over etc...
** Note: thinking about it now, i dont think flag is required in above process, just over complicates it. I will leave it in for now because i know it works, but i will test removing it tomorrow.
Monday Link
Not sure if theres a monday card any more cant seem to find it.
Effected Components
Testing
Ran randomizer and radio receiver until I got no more Parse Fails.
Sanity check
Sources