I now have a "core" firmware that is essentially a stripped down CC firmware that (I believe) correctly presents itself as a PipXtreme. That means that it's using the PipX USB signature and hardware configuration profile. It even shows a PipXtreme graphic on the hardware page when you plug it in!
Currently all it does is configure a USB HID device, which will be used for communicating the the GCS for configuration and stats, etc., and a Virtual Com Port (VCP) device that will be used for the actual message traffic. I'm having some trouble getting a driver loaded on my Win7-64 machine, but I believe the firmware should work. It also configures the UARTS and I wrote a module based on the ComUsbBridge module, called RadioComBridge that I expect to be the basis for relaying data from the USB port/com port to the radio link. It currently just relays from the USB HID device to a com port.
Next we need to get the packetization and radio link working. These parts don't use FreeRTOS, so there's going to take a considerable amount of reworking from expecting a big for loop to being individual threads that wait for data/events and act appropriately. This brings up the question of how much we want to change.
My preference is to add functionality in gradually, and save the bells and whistles for later. This might mean not putting the encryption and/or error correction in at first, which I think is reasonable. A bigger question is if we want to maintain compatibility with the existing PipX protocol, or if we want to rethink it.
This is the current message format:
// encrypted packet format
// 16-byte CBC .. 1st byte must not be zero
// 4-byte source id
// 4-byte destination id
// 1-byte packet type
// 1-byte tx sequence value
// 1-byte rx sequence value
// 1-byte data size
// 4-byte crc of entire packet not including CBC bytes
// unencrypted packet format
// 1-byte null byte .. set to zero to indicate packet is not encrypted
// 4-byte source id
// 4-byte destination id
// 1-byte packet type
// 1-byte tx sequence value
// 1-byte rx sequence value
// 1-byte data size
// 4-byte crc of entire packet not including the null byte
Given that each packet has a source and destination ID, it looks like the intent is to support multiple modems on the same frequency. I haven't seen that in the code yet, so I don't know if it's supported. It would be nice to support multiple modems on slightly different frequencies, but I don't know if that's possible.
I also see references in the code to connecting and disconnecting. I think that a connection less protocol is the way to go. Maintaining connections adds a great deal of complication that I'm not sure we care about.
My thinking on how to implement it is to mimic the USART driver as much as possible, which means that the radio link could look just like another com port externally, and would use a similar fifo buffer. A packet would be sent either when the fifo filled to a certain point, or when a timer expires, which would cause a partially filled message to be sent. There would also have to be an API for inserting priority messages for e.g. PPM packets, etc.
Any thoughts / suggestions?
United States
fw_pipxtreme-2.0-alpha1.opfw 53.4K
4 downloads
CropperCapture1.png 59.73K
17 downloads
Switzerland
Portugal
Australia
South Africa
