Lumpio- has quit [Read error: Connection reset by peer]
Lumpio- has joined #rust-embedded
emerent has quit [Read error: Connection reset by peer]
emerent has joined #rust-embedded
bpye has quit [Quit: Ping timeout (120 seconds)]
bpye has joined #rust-embedded
fabic has joined #rust-embedded
fabic has quit [Quit: Leaving]
fabic has joined #rust-embedded
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter has joined #rust-embedded
fabic has quit [Ping timeout: 260 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 268 seconds]
fabic has joined #rust-embedded
hifi has quit [Remote host closed the connection]
hifi has joined #rust-embedded
fabic has quit [Ping timeout: 256 seconds]
<re_irc> <@ryan-summers:matrix.org> I've had a ton of troubles trying to coerce embedded-time's inner types. There's a lot of where-clausing required
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 268 seconds]
fabic has joined #rust-embedded
<re_irc> <@barafael:matrix.org> any recommendations for a radio solution that can be used for two-way low bandwidth communication of around 1km, and has good rust support? Low bandwidth as in "Remote Control Vehicle/Aircraft control + telemetry"
<re_irc> <@korken89:matrix.org> I used the RFM69 modules for this
<re_irc> <@korken89:matrix.org> Not sure on Rust support, was back in the C days
<re_irc> <@korken89:matrix.org> But it was very easy to work with
<re_irc> <@barafael:matrix.org> thats a cool module. Did you use any antenna with it?
<re_irc> <@barafael:matrix.org> 500 meter range is a little low, but probably can make it work
<re_irc> <@barafael:matrix.org> would prefer to have a little breathing room there :D
<re_irc> <@barafael:matrix.org> tried the hc-12 too, it's good (I even wrote a rust driver for it :) ) but I believe some of its more powerful configurations are actually illegal here in germany.
<re_irc> <@therealprof:matrix.org> barafael:matrix.org: LoRa?
<re_irc> <@barafael:matrix.org> Can I use that for essentially realtime control without violating the bandwidth rules? Something like 1kb/s to 10kb/s
<re_irc> <@therealprof:matrix.org> You can do whatever you want on the ISM bands as long as the signal strength stays within the allowed limits. Not sure what the actual obtainable speed is over that distance.
<re_irc> <@korken89:matrix.org> barafael:matrix.org: I used a normal monopole, and tested up to maybe 300m with good results but maybe it's a bit too weak for your usecase
<re_irc> <@barafael:matrix.org> korken89:matrix.org: thanks regardless! Might be enough for starting out anyway
<re_irc> <@korken89:matrix.org> No problem :)
<re_irc> <@adamgreig:matrix.org> therealprof:matrix.org: A lot of ism bands (in the UK anyway but I think it's harmonised) have duty cycle limits as well as power, and if you want lorawan on top it also has data limits I think? Not a concern for straight point to point lora of course and if you stick to the lower power limits there's not usually a duty cycle limit
<re_irc> <@therealprof:matrix.org> True, ERP and Duty Cycle are regulated. LoRaWAN does have data limits but as you said, I wouldn't see it as a problem in point-to-point use.
<re_irc> <@therealprof:matrix.org> Since that doesn't depend on the actually used protocol/transmission standard the same boundaries apply to all of them. It's just the question who makes most efficient use of the airtime within those constraints. 😉
<re_irc> <@adamgreig:matrix.org> Yea, certainly for 1km remote control at around 1kbps I'd be looking very hard at lora
<re_irc> <@barafael:matrix.org> alright that seems to be the way to go then! I suspected I might have to get into that at some point. Just thought that LoRa would be too low bandwidth, but it seems just fine.
<re_irc> <@newam:matrix.org> barafael:matrix.org: Plugging my pet project: https://github.com/stm32-rs/stm32wlxx-hal
<re_irc> <@newam:matrix.org> The STM32WL has a FSK/LoRa radio built-in. LoRaWAN is still WIP, but the physical layer exists.
<re_irc> <@barafael:matrix.org> Oh really cool, might get away with just one chip then?! Hadn't heard of FSK either
<re_irc> <@dirbaio:matrix.org> how much max range can you get with the stm32wl?
<re_irc> <@adamgreig:matrix.org> "it depends", I've got hundreds of km with same radio part
<re_irc> <@newam:matrix.org> dirbaio:matrix.org: 10km under ideal conditions, but I live in a city centre so I have never gotten that kind of range.
<re_irc> <@adamgreig:matrix.org> Line of sight, big receive antennas, extremely low data rates
<re_irc> <@dirbaio:matrix.org> wow
<re_irc> <@newam:matrix.org> barafael:matrix.org: FSK is frequency shift keying, its a different modulation technique, generally speaking it has higher data rates, lower power per bit transmitted, but worse noise immunity and worse range.
<re_irc> <@adamgreig:matrix.org> Satellite people will win the range records I expect though
<re_irc> <@adamgreig:matrix.org> People have flown that sort of fsk and I think lora radios in a lot of cubesats
<re_irc> <@barafael:matrix.org> newam: anything I need to keep in mind purchasing the WL55 nucleo? Rev. numbers etc
<re_irc> <@newam:matrix.org> barafael:matrix.org: Not that I know of. I would recommend buying two (TX/RX)
<re_irc> <@newam:matrix.org> Oh, there is one thing
<re_irc> <@newam:matrix.org> The JC1 is 915MHz, the JC2 is 433MHz
<re_irc> <@newam:matrix.org> I don't think the JC1's actually exist though, I have only ever seen JC2s for sale.
<re_irc> <@barafael:matrix.org> it's funny, it says it is a JC1 but it also says sth about EU frequency range
<re_irc> <@newam:matrix.org> ISM bands are complicated, I am sure it is licensed for ISM somewhere in Europe 😄
<re_irc> <@therealprof:matrix.org> Yes, there's two versions, one for 868/915MHz and one for 433MHz.
<re_irc> <@therealprof:matrix.org> 868MHz is what you need for Europe.
<re_irc> <@barafael:matrix.org> oh, JC1 just means "around 800-915 mhz
<re_irc> <@therealprof:matrix.org> It's software controlled.
<re_irc> <@newam:matrix.org> The JC1/JC2 difference is just the cap/resistor values on the RF filter.
<re_irc> <@therealprof:matrix.org> ALAS they shouldn't be available... ST still promised to send me one as soon as they have some stock...
<re_irc> <@therealprof:matrix.org> Will ping them for good measure. I really have to get around to playing with that stuff... my LoRaWAN gateway is burning power for now good reason... 😅
<re_irc> <@barafael:matrix.org> interesting, the antenna is the same for both. Thought you need bigger antennas for lower frequencies
<re_irc> <@therealprof:matrix.org> Well, not if the frequencies are multiples (or close to).
<re_irc> <@therealprof:matrix.org> But changing to a better antenna is certainly a good idea for maximum range/performance. 😉
<re_irc> <@barafael:matrix.org> I see... that makes sense :)
jackneillll has quit [Quit: Leaving]
jackneillll has joined #rust-embedded
jackneillll has quit [Client Quit]
jackneill has joined #rust-embedded
<re_irc> <@dngrs:matrix.org> speaking of radio stuff, what's a good solution for minimizing latency? I'm trying to sync LEDs over wifi and the latency spikes are killing meeeeee
<re_irc> <@dngrs:matrix.org> (can't really buffer because I'm doing beat reactive stuff)
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
fabic has quit [Ping timeout: 268 seconds]
zentux has joined #rust-embedded
<re_irc> <@jamesmunns:beeper.com> I don't know how much you can tamp down the latency on wifi
<re_irc> <@jamesmunns:beeper.com> esp 2.4ghz wifi
<re_irc> <@jamesmunns:beeper.com> is it reactive to live audio? Or played audio?
<re_irc> <@jamesmunns:beeper.com> e.g. could you buffer the audio a few seconds ahead, sync time, then send out the beats AOT?
<re_irc> <@dngrs:matrix.org> live
<re_irc> <@dngrs:matrix.org> you were mentioning some nRF radio thing though, I am not strictly speaking married to wifi
<re_irc> <@gauteh:matrix.org> *wify
adamgreig has joined #rust-embedded
Rondom has quit [Ping timeout: 268 seconds]
Rondom has joined #rust-embedded
agg has quit [Ping timeout: 246 seconds]
emerent has quit [Ping timeout: 260 seconds]
emerent has joined #rust-embedded
<re_irc> <@jamesmunns:beeper.com> We just had a convo about the ESB crate on #nrf-rs:matrix.org , might be a good read, or if wires are okay I could probably get you some Powerbus boards :D
adamgreig is now known as agg
<re_irc> <@firefrommoonlight:matrix.org> I'm using it for a 2-part stove thermometer
<re_irc> <@firefrommoonlight:matrix.org> to send temp from an IR sensor mounted above the burner to a screen
<re_irc> <@grantm11235:matrix.org> I am once again trying to figure out how to deal with SPI chipselects in embedded-hal
<re_irc> <@grantm11235:matrix.org> I think that this trait would cover almost all use cases, and it seems pretty ergonomic
<re_irc> <@grantm11235:matrix.org> ```rust
<re_irc> <@grantm11235:matrix.org> /// Inner SPI type
<re_irc> <@grantm11235:matrix.org> type Spi;
<re_irc> <@grantm11235:matrix.org> pub trait Chipselect {
<re_irc> <@grantm11235:matrix.org> I would also like to have some blanket impls like this
<re_irc> <@grantm11235:matrix.org> ```rust
<re_irc> <@grantm11235:matrix.org> where
<re_irc> <@grantm11235:matrix.org> impl<T, W> Write<W> for T
<re_irc> <@grantm11235:matrix.org> T: Chipselect,
<re_irc> <@grantm11235:matrix.org> Which would work fine... IF IT WASN'T FOR THE BLANKET IMPLS FOR REFERENCES THAT I ADDED 😭
<re_irc> <@grantm11235:matrix.org> Instead, I get this confusing error
<re_irc> <@grantm11235:matrix.org> error[E0119]: conflicting implementations of trait `spi::blocking::Write<_>` for type `&mut _`
<re_irc> <@grantm11235:matrix.org> --> src/spi/blocking.rs:93:1
<re_irc> <@grantm11235:matrix.org> |
<re_irc> <@grantm11235:matrix.org> 85 | impl<T: Write<W>, W> Write<W> for &mut T {
<re_irc> <@grantm11235:matrix.org> Is there any way to solve this? I don't even entirely understand what the conflict is, but I have a few guesses
crabbedhaloablut has quit [Remote host closed the connection]
<re_irc> <@grantm11235:matrix.org> The intended use is for HALs to impl Chipselect for `MySpiMutex<MySpiBus>` or whatever
<re_irc> <@dirbaio:matrix.org> oh yeah the `downstream crates may implement` error is super confusing
crabbedhaloablut has joined #rust-embedded
<re_irc> <@dirbaio:matrix.org> I still don't understand it
<re_irc> <@dirbaio:matrix.org> like
<re_irc> <@dirbaio:matrix.org> why can't the compiler reject these hipothetical impls in the downstream crates?
<re_irc> <@grantm11235:matrix.org> I think the problem is that two different crates could impl stuff that is fine on it
<re_irc> <@dirbaio:matrix.org> hmm, how?
<re_irc> <@dirbaio:matrix.org> like
<re_irc> <@grantm11235:matrix.org> You don't want a compiler error just from importing two perfectly legit crates
<re_irc> <@grantm11235:matrix.org> Hold on, I think I have a minimal example somewhere
<re_irc> <@xiretza:xiretza.xyz> the blanket impl is in the same crate as the trait, right? so in order for another crate to impl the trait, it also has to know about the blanket impl
<re_irc> <@grantm11235:matrix.org> I ran into a similar problem with the e-h `Default` marker traits
<re_irc> <@dirbaio:matrix.org> okay so the conflict would be if
<re_irc> <@dirbaio:matrix.org> downstream crate does
<re_irc> <@dirbaio:matrix.org> struct Foo
<re_irc> <@dirbaio:matrix.org> impl Chipselect for &mut Foo
<re_irc> <@dirbaio:matrix.org> impl Write for Foo
<re_irc> <@dirbaio:matrix.org> ```rust
crabbedhaloablut has quit [Remote host closed the connection]
<re_irc> <@dirbaio:matrix.org> that would summon two incompatible impls for `Write for &mut Foo`
crabbedhaloablut has joined #rust-embedded
<re_irc> <@grantm11235:matrix.org> No one should need to impl `Write` and `Chipselect` for the same struct, but I don't know how to enforce that in a way that rustc understands
<re_irc> <@dirbaio:matrix.org> yeah... I don't think there's a way to enforce that
<re_irc> <@dirbaio:matrix.org> what I don't get is why doesn't Rust forbid that in downstream crates instead
<re_irc> <@dirbaio:matrix.org> maybe it's too expensive to compute or something? np-complete halting problem something something? 🤣
<re_irc> <@grantm11235:matrix.org> Do any of those "confusing errors are bugs and I will fix them" people hang out in this channel?
tokomak has joined #rust-embedded
<re_irc> <@dirbaio:matrix.org> the MVP is this
<re_irc> <@dirbaio:matrix.org> ```rust
<re_irc> <@dirbaio:matrix.org> trait Bar {}
<re_irc> <@dirbaio:matrix.org> trait Foo {}
<re_irc> <@grantm11235:matrix.org> I am a "confusing errors are bugs" person, but I don't know how to fix it 😛
<re_irc> <@dirbaio:matrix.org> I think there's nothing to fix, it's simply the way it works...
<re_irc> <@dirbaio:matrix.org> I think what's going on is
<re_irc> <@firefrommoonlight:matrix.org> ```rust
<re_irc> <@firefrommoonlight:matrix.org> pin.set_low();
<re_irc> <@firefrommoonlight:matrix.org> fn do_thing_on_spi(spi: &mut Spi<SPI1>, cs: &mut Pin) {
<re_irc> <@firefrommoonlight:matrix.org> spi.write(&data);
<re_irc> <@dirbaio:matrix.org> when rust checks for conflicting impls `impl Foo for X`, `impl Foo for Y` it asks the question "can X and Y overlap?"
<re_irc> <@dirbaio:matrix.org> `&mut T where T: Foo` and `T where T: Bar` definitely can
<re_irc> <@grantm11235:matrix.org> dirbaio:matrix.org: I mean fix the error message so that it makes more sense
<re_irc> <@dirbaio:matrix.org> and downstream crates will be allowed to do the evil impls because they don't violate the "can X and Y overlap?" themselves
<re_irc> <@dirbaio:matrix.org> they're just causing *other* impls to violate it
<re_irc> <@dirbaio:matrix.org> if Rust allowed the upstream crate's impls, it'd have to do way more complex checks on downstream impls
<re_irc> <@dirbaio:matrix.org> so taht's probably why
<re_irc> <@dirbaio:matrix.org> I'm not sure how would you improve the error though
<re_irc> <@grantm11235:matrix.org> Well for starters, the last line is repeated for some reason