The unacknowledged command list on the GCS is brilliant - might adopt that for my stuff too! Glad to see you landed on sending multiple separate telem packets instead of a long string! I wish I had started doing that earlier, would have saved me a lot of trouble haha. Great video as always!
@@AeonExploration🔴 What Is Islam? 🔴 Islam is not just another religion. 🔵 It is the same message preached by Moses, Jesus and Abraham. 🔴 Islam literally means ‘submission to God’ and it teaches us to have a direct relationship with God. 🔵 It reminds us that since God created us, no one should be worshipped except God alone. 🔴 It also teaches that God is nothing like a human being or like anything that we can imagine. 🌍 The concept of God is summarized in the Quran as: 📖 { “Say, He is God, the One. God, the Absolute. He does not give birth, nor was He born, and there is nothing like Him.”} (Quran 112:1-4) 📚 🔴 Becoming a Muslim is not turning your back to Jesus. 🔵 Rather it’s going back to the original teachings of Jesus and obeying him. More .....👇 🔴 THE RETURN OF JESUS
@@potatosalad68 I apologise if my comment sounded disingenuous. It wasn't meant to be. Such was the extraordinary effort put into the telemetry side of the project, it seemed, at least to me, a shame that wasn't put into a vehicle that reached the edged of the atmosphere. Everyone's interests, needs and level of fulfilment are different, obviously, but for me it would have been smashing to see it last more than a few seconds of flight - sort of extending the excitement for longer or expanding on the experience. I have a similar dilemma here in the UK but in terms of model UAV flights. Here we're forbidden to fly out of sight. Therefore, the type of aircraft I would like to fly, including their telemetry systems and their missions is out of the question. The fun police have put a stop to out of sight model flying after a nutter flew a drone too near aircraft at an airport as part of a harassment-come-protest campaign a few years ago. Either way, it [the rocket project] is fantastic work.
Great treatment of the problem. Using "escape characters" are also a good way of dealing with important control characters (such as Start Of Packet, End of Packet etc) appearing in your data payload. The benefit of "escape characters" are that they can be inserted at the moment of transfer of the data to/from the microcontroller to/from the radio. They do not need to be computed beforehand. They just get inserted in the stream before transmission and extracted from the stream after reception. As an aside, It would be interesting to learn if your radio supports Forward Error Correction as a means of recovering from short bursts of noise.
Wouldn't that just shift the problem from having a data byte with the same value as the start byte, to having a data byte with the same value as the escape byte?
@@tijsp.8162 no, there is some particular logic around this solution. Two consecutive escape characters are considered as one data character equal in value to the escape character. Only control characters are preceded by a single escape. Any other character not preceded by an escape character is considered to be itself. It’s absolutely bombproof and works really well at very high speeds in low resource microcontrollers. It’s as old as the original serial port standards and works just as well today.
I think you COULD check the whole packet: since the value of the last COBS byte is almost freely chosen (anything from 29 to 255 is possible), if the CRC evaluates to 0xAA, just change one bit of that byte and the CRC will now be different ;)
For your int16_t fields.. Consider encoding as sign + magnitude instead of twos complement. This allows you to do things like varint (Protobuff) or better use zeroes-only compression (Capn-Proto). The assumption is that the control values will tend to reduce in magnitude as the control system zeroes in on its target. Great videos BTW!
One improvement you can do to the protocol parser is to store command codes + function pointers in a look up table, that you just iterate through. That gets rid of the switch statement and consolidates the entire protocol definition in one table, separate from the functional code. One step up is to keep the protocol structure separately in a JSON file or similar and generate .c/.h files as a build step. That way you don't need to mess with the code at all if you make changes in the protocol.
@@homeopathicfossil-fuels4789 you can parse commands from a separate thread, but that's not necessary. This is more about the logical organization of the protocol processing rather than a functional change.
@@frigzy3748 no indirect threading is interpreter speak, not threading as in hyperthreading or such. A lot of Forth's use indirect threaded interpreting, i.e you got a bunch of subroutines in memory that do their job then instead of returning they increment a pointer to a list of pointers to subroutines then jump to the next subroutine referenced in that list. It is a quite fast method of parsing/interpreting.
Thanks for the video. I'm actually looking to implement some sort of network protocol for my custom-made devices, and it helped me tremendously to get the basic os COBS and how different layers relate. Can't wait for the more in depth video!
How often does a command go unacknowledged? IIRC, for the PSAS rocket we had to do unacked UDP because TCP was taking too long at Mach 3. Also, do you have a way of indicating which commands are okay to retry? The launch command probably shouldn’t trigger twice for instance.
On the ground, maybe 1 in 10 commands goes unacknowledged. It depends on distance, antenna geometry and noise floor though. The re-try on some dangerous commands is a good point though. Currently, I only allow about 5 retry attempts with a re-send every 400ms. That means if the command doesn't go through in 2 seconds, it stops trying to send. Currently, that is uniform across every command, but you could totally implement different max re-transmit attempts or different re-transmit delays for each command. I'll add that to the list of future link improvements!
Have you considered adjusting the lowest layer based on what your transport medium is? For a radio protocol that is already doing all the framing for you, you should be able to skip a lot of the line coding overhead and get better performance. Your XBee modules probably already do all of the preamble and start/end of frame detection for you. This isn't really any different from how a lot of other layered protocols are done, for example Ethernet's link layer doesn't worry about any line coding (just addressing and checksumming) and the scrambling encoding etc is all done in the PHY chip which will vary depending on whether you're running over 10baseT or 200G fiber or whatever. So you can keep a common upper layer protocol suite but then vary the lowest coding layer depending on the media in question.
Awesome work, love this series! Regarding multiple transceivers communicating over a shared channel (i.e. radio), do you need to use a multiple access protocol to avoid collisions between messages sent at similar times, or are such issues generally handled within the physical layer or by the checksum?
Great video, thank you for sharing! How does COBS handle 170 appearing across bytes? For example 0b00001010 (dec 10) followed by 0b10100000 (dec 160) will appear to have 0b10101010 if the message starts to get read partway through. It seems your scheme would work if the starts of bytes are synchronized, but depending on the physical layer, I feel like you may have times when you get a corrupt packet which happens to have an unfortunate 170 in the middle. (or maybe this is rare enough that it does not matter and is handled by the checksum etc.?)
Super great explanation. I wondered at the choice of the start byte: Since it is a periodic pattern (10101010), is there not an increased chance it will be falsely received/sent by some physically occuring periodic oscillation/signal/noise whatever?
Here's my thought process, not sure if it's a good one: Especially when using something like UART, I wanted to make sure a line open or short wouldn't parse correctly. Using 0 or 255 as a delimiter might have that problem. I also wanted to make sure the transmitter and receiver had the same baud rates. I figured if they didn't, the likelihood of receiving this periodic start byte successfully would be low, so we wouldn't risk parsing a packet with an incorrect baud rate. If we did, we could interpret one command as something totally different, though the checksum should prevent these packets from being executed 255/256 times.
@@LafayetteSystems That makes sense. I am by not an expert on communication protocolls but have a physicists perspecive. As such, it seemed to me that if there is some EM signal induced somewhere, it would have a good chance of being periodic. That said, I have no idea if this is a real problem in rocket electronics, so feel free to dismiss my input. With baud rates being somewhere in the upper acoustic one could feasibly imagine vibrations somehow coupling to the electronics (induction, piezoelectricity or just a bad contact somewhere). Admittedly, this is more or less far-fetched. I believe your arguments would still hold for a not perfectly periodic checksum like 10101110? Depending on how easy it is to swap the start bit one could probably test how many false checksums one gets for different start bits. But I guess that is a bit much effort as long it works either way :-P It is pretty awesome to see what you are kitting together :D
I have a fairly similar packet implementation as yours, and what I'd recommend is that to use COBS to escape 0x00, and set the start byte to 0x00. So as long as your length of your payload is not 0 (which is always the case), you won't run into having several start byte in your header. In your example, the SCAPL might run into issue when length == 170
I was just thinking about systems that simplify the amount of work you have to deal with at a base station and for the rocket to autonomously do most of it. However this would be more so for small or simple rockets. Making a set of systems to deal with different stages or of the launch, like a set of numbers. The downside to this is that you don't receive flight data from the rocket, but the upside is that you only have to transmit very small commands, basically like saying 1 to begin preflight checks, 2 to launch, 3 to begin, 4 to adjust to a certain AOA, etc. (this could also even just be the specific radio frequency but that might have its flaws).Now that i think about it its sounds less efficient and means you cant learn anything about the flight performance of the rocket lol. Nvm forget i said anything
Do you think you could need a version byte at some point, or are you just be going to keep all rockets and launchers in sync. COBS does seem clever - I have been recently experimenting with sending binary data over serial (which is how I found out Arduino Unos use 16 bit integers!) and was wondering about what to use as a start header. I will probably just use two bytes so i can use a number that definitely isn't within my data range. I am using it for a robot remote controller.
I believe the language of the law is indeed “guided” vs “stabilized”. Curious how this fits in. Telemetry data and two way coms are not an issue, so I guess it would come down to if you’re using those to guide the rocket or just communicate flight data.
@@garrettwalton7461 thanks, yea i was confused cuz ive been seeing people starting to make more and more videos about making guided rockets i didnt know if they relaxed the regulation or not
As long as you're a US citizen, the only thing ITAR really prevents you from doing is exporting the controlled item (software, physical piece of gear, whatever). The legalese is a bit more complex but generally speaking you can build all the ITAR controlled hardware you want, as long as you don't take it out of the country (including posting controlled digital assets such as source code somewhere that a foreign national could access it) or give it to a foreign national within the US. The biggest headache is that if your PCB designs end up ITAR you can't use cheap Chinese manufacturers to fab the boards, so things cost way more. One of the open challenges on my long term dream of putting a phased array radar up on my roof is that I'd like to figure out a way to avoid the the PCBs being ITAR (i.e. either build generic hardware that's not "specially designed" for this purpose, or just use a bank of off the shelf SDRs). If the software is controlled that's not a big deal as it doesn't cost me any more money to do the project, I just can't open source the code. But dotting the Is and crossing the Ts right would require retaining an export lawyer, which would cost enough that the project has remained on my wishlist for years without any active progress.
Coming to this discussion late (for anyone after me), yeah ITAR is about export of restricted data but there's another regulation called the USML (US Munitions List) under the Code of Federal Regulations. This directly falls under 22 CFR 121.1, Category IV: Launch Vehicles, Guided Missiles, Ballistic Missiles, Rockets, Torpedoes, Bombs, and Mines. There is a note under section A which specifies model rockets do not fall under this list for regulatory purposes (they live elsewhere), however model rockets must not contain active control i.e. RF/GPS/etc. I work in this industry and we have to abide by both ITAR and the USML. I also looked into something like this 5 years ago after college to practice my technical skills and ran exactly into this issue.
How important is compression? It takes more on board CPU power, but if you're having trouble getting enough bits up or down in time, I'm pretty sure there are more efficient (group theoretic) algorithms available.
Depends on how efficient your data is structured on its own. If you are including 4 bytes float for each variable, but in reality they have very limited range, compression can have a huge effect. If you manually arrange your data efficiently, e.g., using 2 byte integers to represent each variable (with a fixed number of after comma positions), you are doing the compression 😂 Information Theory provides the theoretical limits: The shortest achievable average length of your messages is the entropy of your source. Systematic compression can get you very close independent of how you structure your data. But if you are close enough using the manual optimization, the extra overhead for a minimal performance gain is not worth it.
And this mainly applies to the telemetry packets. While also theoretically applicable to command packets, I only have experience transmitting one command per packet. In this scenario the packets are very short and thus compression does not make sense.
Just a quick question, why don't you just ignore the start byte if it ever shows up in the packet if that byte is still within the length specified at the beginning instead of doing COBS?
On most radio modules like XBee, you can enable built-in encryption! I don't encrypt commands sent over wired connections though, seems like we have bigger problems if someone else is sending commands over my own USB cable :)
MAVLink is very cool, its more complicated but also more robust than the architecture I use. It should totally work for an application like rocketry but includes more overhead.
I am wondering why didn't you use some already established protocol like Mavlink ? You just wanted to challange yourself (which is good I suppose) or existing solutions didn't meet yout needs?
I guess, Express LRS is too rigidly intertwined with the RC models, you cannot just send arbitrary data through it, at least not in an efficient way. Without the RC model stuff, it becomes just LoRa which is what he is probably using.
4 месяца назад
ExpressLRS recently added the AirPort feature, that behaves like a mostly transparent serial link.
Good question! That's where the packet length limit comes in. They can only be 32 bytes long, so our highest payload length is 28 bytes so we will never have to put 170 there. This does mean the payload could be up to 169 bytes long without running into any issues, but I've had problems getting packets that long to send reliably.
The worked example video will talk a bit more about this, should be released in the next few days. The short answer is you send the value in question in different units. If you want to send volts with 3 decimal places, you send the value in question as an integer in millivolts and then convert back to volts (with three decimals) on the ground control software. If you want meters with 1 decimal, you send as an integer in decimeters and again convert back to meters with 1 decimal on the ground control software.
@@RiwenX LORA is indeed good, but not for this application, Airtime of the signals is quite high, so we can't get data too quickly from Flight Computer to the ground station.
Why so much documentation? Why so much formalism? Is this for a university or is it just a hobby? Eitherway interesting to see how you did the datalink. I have a personal problem with my code where its very braindead simple and unorganized. Its easy to make up at first, but then its difficult to expand on later lmfao.
Do you use multiple antenna or how do you solve the problem of the ground station and rocket sending repeatedly at the same time and how long do those transmissions last? If you essentially have to hit two 100 ms windows every second, it might be a good idea to add a clock sync. Depending on how much data you downstream.