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 місяці тому+2
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.
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!
how do i get that document.
Guys - Collab !
These guys can make a missile if they collab 😂. They can also add Nile Red for the chemistry on propellant and explosives
Seriously? you're saying this is the first time you've encountered the ack-nak concept?
Bipispace uploaded the same day as you, what a blessing
ah yes bipispace
I think you meant BiPiEsSpace
@@MionwangI'm more interested what he did to make his autocorrect go there.
Little competition going on? haha
@@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
The telemetry theory and practice in itself far more satisfying than the "Ssssssshhhhhhhhf.....Phut!" of a 5 second model rocket flight.
both. both is good
@@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.
bro gotta be on a watchlist by now
"Error correction that I made myself", I see you like to live dangerously. 😂
"this guy fucks"
And painfully apparently
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 ;)
That's an interesting idea, I'll have to give it a try!
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.
indirect threading for command parsing?
@@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.
You AND Joseph posted on the SAME DAY? Am I dreaming?
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!
Great video, I am really interested in the avionics part. If you could make a even more deeper dive than your previous video that would be great
tutorials for making precision guided munitions? lovin it!
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.
Very cool and good video, I would appreciate more expanding on the topic in depth.
Another great video, I love this rise in advanced model rocketry!
Interesting 🤩 go further in details in next videos, do some tutorials for rocketry and control systems enthusiast we will really appreciate it
Oooh, if you implement Hamming codes, that would be cool to see.
That's amazing. Really interesting and very cool. Have you thought about releasing the system specification for others to use ?
Would chirped spread spectrum be a good candidate for the physical layer?
There are some high speed LORA chips that could handle the bandwidth needed.
i dropped my coffee on my board at 2:25, thanks a bunch T.T
Have a pair of RFD900s, they're insane.
"If you have ideas, implement them in your own protocol" The polite way to say "Shut up, I don't want your input"
i love this, i’m definitely going to use stuff like this in the future.
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?
Amazing Work! Next Time can you Introduce your First Assistant that shows in 0:14 ,Thanks and Keep up The Great work.
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.?)
What if the index that is held by the COPS byte is 170?
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
Why RS422/485 over CAN? I'm just getting into a project doing a similar thing and am curious if it might be better to go with one of those?
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.
This rocket is a Foxy One.
Doesn't this violate ITAR? I thought we couldn't make guided rockets? Or is it autonomously guided that's prohibited without a license?
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.
You could get rid of the COBS stuff by just checking the length number when a 170 is seen. If position is less than length, it's not a new message.
COBS is needed ONLY when the protocol specifies that it handles start and stop bytes.
If you're making your protocol, you don't have to use it.
@@pierro281279 Re-read the first word of my comment again.
Do you have any other recommendations for resources that you used to learn this? I’m really interested in your work it’s awesome man.
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?
would you ever consider adding encryption of some sort?
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 :)
What rocket motor are you using
for small rockets like this, whats the fuelused being used?
Curious if you've tried Mavlink or have experience with how robust it is for your use case?
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.
@@LafayetteSystems interesting good to know. I know it's widely used but wasn't sure since Mavlink is relatively old
this is soooooooo cool!
How about FSK on a LoRa chipset, it can do around max 300kbit/s. It’s on the 868mhz/915mhz for longer range comunication
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?
Wow! Just discovered your channel, and… yeah. Insta-sub.
What about data encryption?
Why not use something existing like ExpressLRS?
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.
ExpressLRS recently added the AirPort feature, that behaves like a mostly transparent serial link.
What is the range of ur data link connection?
ขอบคุณมากครับกับสาระดีๆ
What is the range of the radio transmitter?
So what hardware are you using after all?
10:24 and what if that index too is 170? I mean, we can have as many indexes as we want since it is variable length, right?
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.
What is the range of this receiver
7:00 how do you make an int value represent a number with stuff after the decimal point?
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.
where do i get that document .
Now I know why I hate my Long Range LORA SX1262 Radio Transceivers
Why? LoRa is amazing
@@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.
@@ArifKhan-bp9zx How much data are you sending?
Momo should be in every video
Bro is making guided rockets even legal?
Hell Yeah!
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.
I would be worried a command would be sent multiple times, if the acknowledgement wasn't received
I think adding a number to serialize the commands might be helpful, so that the receiver can tell if it receives two copies of the same command.
This is inspiring/
Deberías hacer contenido en español 👍
Cool
Now Bro is inventing homemade Link-16💀💀💀
Is this even legal?
Why wouldn't it be.
Yes
man would built a rocket from scratch than to talk to girls (its me, I'm also that man)
1960s tech
What the heck was I doing studying law?? I could be doing cool stuff such as these😢
Why would you make something like this?? You better just try to make the rocket go up only alright?
13+ minutes of software and nothing on hardware.
😂😂😂😂
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.