For the purposes of this, assume that brrrrrrt is supposed to sound like a machine gun (spoiler, it doesn't).
With a musket, you fire once, reload, fire again, etc.
So it sounds like "Bang! Interval. Bang! Interval. Bang! Interval. Etc etc", in contrast with a machine gun.
For the purposes of this, assume that brrrrrrt is supposed to sound like a machine gun (spoiler, it doesn't).
With a musket, you fire once, reload, fire again, etc.
So it sounds like "Bang! Interval. Bang! Interval. Bang! Interval. Etc etc", in contrast with a machine gun.
Keeping it short, I hate the 'go brrrr' thing under any context with a deep and hot passion. I've heard A-10 gun runs in person and even 'brrrt' doesn't do any justice to the level of acoustic violence the GAU-8 Avenger is capable of.
Imagine the sound the worlds most enormous dragon would make if it was trying to gargle the worlds largest running buzzsaw whilst spitting out supersonic milk bottle sized explosive ammunition at several thousand rounds per minute.
Allow me to hijack this thread for some of my future electronics projects ; ]
I've been playing around with the pi pico recently, and I decided that I could probably use the programmable IOs to read an sbus protocol from a receiver instead of reading PWM signals with interrupts. Perhaps (probably, in fact) there exists a better way to do this than what I am showing here, it was interesting none-the-less.
Below is the C code, written using theC/C++ SDKprovided by Raspberry.
The programmable IOs are programmed using a language that's basically assembly if I understand correctly. Here's what I came up with. This is pretty ugly, and maybe could be done better...? But if it aint broke, don't fix it, and I barely know what I'm doing.
.program sbus
.wrap_target
wait 1 pin 0 [31]
set x, 24 [15]
byteloop:
nop [3]
in pins, 1 [3]
in pins, 1 [3]
in pins, 1 [3]
in pins, 1 [3]
in pins, 1 [3]
in pins, 1 [3]
in pins, 1 [3]
in pins, 1 [3]
jmp x-- byteloop [11]
irq set 0
in null, 31
in null, 31
in null, 2
.wrap
And here's the output. Sbus can transmit up to 16 channels, but my transmitter only has 8.
1036, 1060, 1516, 1041, 1047, 940, 1847, 457
The values are in the range of 192 - 1792.
The connection diagram is super simple, since sbus is a single-wire protocol.
I spent about a week on this, maybe not worth the time. Maybe the uart can be configured somehow to read the signal. I'm sure PIOs will be useful for other stuff.
Allow me to hijack this thread for some of my future electronics projects ; ]
I've been playing around with the pi pico recently, and I decided that I could probably use the programmable IOs to read an sbus protocol from a receiver instead of reading PWM signals with interrupts. Perhaps (probably, in fact) there exists a better way to do this than what I am showing here, it was interesting none-the-less.
Below is the C code, written using theC/C++ SDKprovided by Raspberry.
The programmable IOs are programmed using a language that's basically assembly if I understand correctly. Here's what I came up with. This is pretty ugly, and maybe could be done better...? But if it aint broke, don't fix it, and I barely know what I'm doing.
.program sbus
.wrap_target
wait 1 pin 0 [31]
set x, 24 [15]
byteloop:
nop [3]
in pins, 1 [3]
in pins, 1 [3]
in pins, 1 [3]
in pins, 1 [3]
in pins, 1 [3]
in pins, 1 [3]
in pins, 1 [3]
in pins, 1 [3]
jmp x-- byteloop [11]
irq set 0
in null, 31
in null, 31
in null, 2
.wrap
And here's the output. Sbus can transmit up to 16 channels, but my transmitter only has 8.
1036, 1060, 1516, 1041, 1047, 940, 1847, 457
The values are in the range of 192 - 1792.
The connection diagram is super simple, since sbus is a single-wire protocol.
I spent about a week on this, maybe not worth the time. Maybe the uart can be configured somehow to read the signal. I'm sure PIOs will be useful for other stuff.
Why on earth did the person who designed this put the CND pin next to the GND pin! Head scratching guaranteed.
Edit:
Jesus Christ, why the heck can I hear it? Have I broken it?
Edit2:
I've tested all of my ultrasound sensors, and they're operating at a resonant frequency of 95 Hz.
Oddly enough, they work, kinda.
Edit3: So I just checked the internet, and apparently that's just another ground pin. That's mildly reassuring, but why are all my ultrasound sensors buzzing?
Why on earth did the person who designed this put the CND pin next to the GND pin! Head scratching guaranteed. View attachment 95029
Edit:
Jesus Christ, why the heck can I hear it? Have I broken it?
Edit2:
I've tested all of my ultrasound sensors, and they're operating at a resonant frequency of 95 Hz.
Oddly enough, they work, kinda.
Edit3: So I just checked the internet, and apparently that's just another ground pin. That's mildly reassuring, but why are all my ultrasound sensors buzzing?
Yeah, it's a US-100. I bought it because it has uart communication as well as the classical HC-SRF04 communication protocol, although I haven't gotten it to work. I'm kinda giving up on it now, I'm going to try to rely solely on an BMP280 for alititude estimation. The ultrasonic sensor would only work for like 5 meters or so...
Yeah, it's a US-100. I bought it because it has uart communication as well as the classical HC-SRF04 communication protocol, although I haven't gotten it to work. I'm kinda giving up on it now, I'm going to try to rely solely on an BMP280 for alititude estimation. The ultrasonic sensor would only work for like 5 meters or so...
Whilst we're at what our dads built... my dad once built a Stirling engine out of Merkur. I never saw it run though, and it's been disassembled for a long time.
This from the DSHOT protocol for ESCs. Why on earth would they represent 1s and 0s like this?
This is going to be a pain in the bum to implement with the PIOs on the raspberry pi pico for my drone project.
I'm still going to do it, because Bluejay doesn't seem to support PWM signals (I've tested it), and unlike BlHeli_S, it can play nice tunes on the motors.
In the end, it was actually quite simple to implement. Or rather, the code required is simple, debugging it was hard.
Here's the PIO assembly code:
.program dshot
; sm set to 2.4MHz for a 300Khz baud, so 1 bit == 8 cycles
.wrap_target
pull block
out null, 16
set x, 15
bitloop:
set pins, 1 [2]
out pins, 1 [2]
set pins, 0
jmp x-- bitloop
.wrap
If anyone wants me to explain what each line does, I'll do it, but otherwise I won't waste space, haha. There's also some setup code in the main c file, but it's similar to what I did with SBUS in one of my previous posts on this thread.
Interestingly, Dshot150, the 150Kbaud version of the protocol, doesn't work with my Chaos 20A ESCs, while the faster Dshot300 300Kbaud one works just fine.
Welp, if I'm ever going to need to increase my PID loop frequency, I can go to like 16Khz before I'm limited by the transmission speed, but I think my 450mm quad will do just fine with 500hz.
This has no real benefit for me, except for the fact that I can now make the motors play a melody on startup, which automatically makes it like 10x cooler. So, so worth it!