GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Excess Flood]
GenTooMan has joined #rust-embedded
starblue1 has joined #rust-embedded
starblue has quit [Ping timeout: 240 seconds]
<re_irc> <@f​irefrommoonlight:m​> I dunno
<re_irc> <@f​irefrommoonlight:m​> I found one that works and went with it. Mcp1802
<re_irc> <@f​irefrommoonlight:m​> FYI, an important consideration is quiescent current
<re_irc> <@f​irefrommoonlight:m​> The one I posted is good for batteries. If you use one with mA QI, your battery life will hurt
<re_irc> <@f​irefrommoonlight:m​> Also look at dropout voltage if your input voltage is close to output
<re_irc> <@f​irefrommoonlight:m​> Use LDO if this is the case, or might be the case with sagging battery V
<re_irc> <@f​irefrommoonlight:m​> also look at how much current it can output
<re_irc> <@f​irefrommoonlight:m​> Basically... Figure out what your requirements are, and pick one that meets them, is cheap enough, is in a small enough package, and is available
<re_irc> <@f​irefrommoonlight:m​> If you don't know what your requirements are, pick a rando one
<re_irc> <@f​irefrommoonlight:m​> And go with a new design. They're generally better. The old ones are there for existing designs
<re_irc> <@k​evlan:m​> I would also add to look at modules of you need a switching regulator. I've used ones from TI before that have the inductor and small capacitors integrated so there is very little design work needed. If you aren't using high volumes the design time saved and the smaller bill of materials is well worth it.
<re_irc> <@f​irefrommoonlight:m​> As opposed to designing the regulator with analog components? Or have I been doing something catastrophically wrong??
<re_irc> <@l​uojia65:m​> jamesmunns:
<re_irc> <@k​evlan:m​> firefrommoonlight: It's typically not difficult to get a buck regulator design from discrete components to "work" but getting the optimized component selection and layout for the best frequency response, EMI performance, and efficiency can take some iterations.
<re_irc> <@k​evlan:m​> When I'm doing low volume stuff I typically reach for modules like this one that basically take the need for all of that design work away. It's as easy as designing in a linear regulator but with the efficiency benefits of a switching regulator.
<re_irc> <@f​irefrommoonlight:m​> Gotcha. I'm actually read through some relevant sections of The Art of Electronics today, although mostly AC to DC regulators etc. Seems like a good way to learn more. (Designing a regulator on paper, or in a real circuit) In the realm of powered an MCU and similar components -as you said - you will...
<re_irc> ... likely not do better in cost, performance, or time by designing by hand
<re_irc> <@f​irefrommoonlight:m​> Ie, buy a SMT regulator IC
<re_irc> <@f​irefrommoonlight:m​> unless you're doing something beyond its capabilities
<re_irc> <@f​irefrommoonlight:m​> Btw, another approach is to pick your favorite IC company, and search through their catalog
<re_irc> <@f​irefrommoonlight:m​> Analog Devices has a very nice sort/filter/search system
<re_irc> <@f​irefrommoonlight:m​> For example:
<re_irc> <@f​irefrommoonlight:m​> So, let's say I'm looking for a regulator for a small battery-powered MCU and sensors etc
<re_irc> <@f​irefrommoonlight:m​> I could go to this page: put in the specs I want, leave the default sort of New in, and pick one towards the top
<re_irc> <@f​irefrommoonlight:m​> Maybe price shop a bit
<re_irc> <@f​irefrommoonlight:m​> Note that because that category is LDO, you can expect them to have small dropout voltages
<re_irc> <@k​evlan:m​> firefrommoonlight: Price shopping at analog devices is a bit of an oxymoron.
<re_irc> <@k​evlan:m​> For general purpose use most LDOs will probably do the job. They are usually very easy to design around and hard to mess up as long as they meet the specs you need and have good thermal management using the pcb.
<re_irc> <@k​evlan:m​> It's switching regulators where things get a bit more interesting and even with using switching regulator ICs that the design can be more difficult.
<re_irc> <@k​evlan:m​> I actually have a YouTube series that I am working on where I go through my design process and some testing to compare some different buck regulators. I am targeting a 24v to 5v at~5A for these which is a lot of power for most embedded applications but the design principles are the same for lower power and...
<re_irc> ... voltage systems.
<re_irc> <@k​evlan:m​> The layout video covers most of the parts that are critical for buck regulators to meet EMI requirements.
fabic has quit [Ping timeout: 250 seconds]
fabic has joined #rust-embedded
<re_irc> <@f​irefrommoonlight:m​> That's cool!
fabic has quit [Ping timeout: 252 seconds]
tokomak has joined #rust-embedded
Abhishek_ has joined #rust-embedded
fabic has joined #rust-embedded
GenTooMan has quit [Ping timeout: 250 seconds]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Excess Flood]
GenTooMan has joined #rust-embedded
zBeeble has quit [Remote host closed the connection]
zBeeble has joined #rust-embedded
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Excess Flood]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 250 seconds]
GenTooMan has joined #rust-embedded
Abhishek_ has quit [Quit: Connection closed for inactivity]
<re_irc> <@j​amesmunns:m​> kevlan: Oh hey, I feel like I should chat with you :D
<re_irc> <@j​amesmunns:m​> I'm literally designing a bus for my home that does 20V3A on the line, so I can have each node step that down to 5V
<re_irc> <@j​amesmunns:m​> 20V, because I plan to power the bus with USB-PD :D
<re_irc> <@j​amesmunns:m​> Right now I'm using a super jank DC/DC buck from AliExpress:
<re_irc> <@j​amesmunns:m​>
<Lumpio-> I'm pretty sure you can get a less jank DC/DC converter without all the complication of USB PD
<re_irc> <@j​amesmunns:m​> (it uses Ethernet cables for the bus, with 3x 20V power pairs, and one rs485 pair
<Lumpio-> woo @ RS-485
<re_irc> <@j​amesmunns:m​> Lumpio-: I'm just using USB pd as the baseline for power injection. The nodes themselves don't have USB
<Lumpio-> Does it use a separate RS-485 converter for each port or what
<Lumpio-> Also why are the ports "A B P A"
<re_irc> <@j​amesmunns:m​> It has two rs485 xcvrs
<re_irc> <@j​amesmunns:m​> One is hooked up to both A ports for daisy chaining, one is hooked up to B with a termination resistor
<re_irc> <@j​amesmunns:m​> P is for power injection
<Lumpio-> What liek a port with just power or?
<re_irc> <@j​amesmunns:m​> So if you had a bus of three devices, you'd use the B port on each end, and the middle device would use both A ports
<re_irc> <@j​amesmunns:m​> Lumpio-: Yup
<Lumpio-> mm-hm
<re_irc> <@j​amesmunns:m​> I'm working on routing so you can fork the bus into basically a whole tree of devices
<re_irc> <@j​amesmunns:m​>
<re_irc> <@j​amesmunns:m​> I'm currently working on the bus discovery code, using async, some psuedocode here:
<re_irc> <@j​amesmunns:m​> Feel free to join if this is interesting to y'all. I talk about a lot of projects there, and this is the currently active one :D
<Lumpio-> I did a device discovery thing based on bit prefixes and hashes but I'm not sure if it scales up (or if there can be bad collisions)
<Lumpio-> On RS-485
<re_irc> <@j​amesmunns:m​> Yeah, I'm doing it with that, + jitter, + you have to ack three times successfully to get a "lock"
<re_irc> <@j​amesmunns:m​> I'm hoping that's enough to avoid problems
<re_irc> <@n​ihal.pasham:m​> been dealing with a couple of issues today. This one, I was not expecting.
<re_irc> <@n​ihal.pasham:m​> I ran into this issue - , which was reported a while back. I've double-checked the documented solution i.e.
<re_irc> <@n​ihal.pasham:m​> - have `use defmt-rtt as _` as my global logger in my
<re_irc> <@n​ihal.pasham:m​> - and I can see double quotes being around `"_defmt_version_ = 0.2"` when I grep for the .defmt symbols.
<re_irc> <@n​ihal.pasham:m​> So, not sure, what else could be going wrong here.
<Lumpio-> Didn't even bother with jitter or multiple acks
<re_irc> <@j​amesmunns:m​> I'd definitely suggest opening a new issue nihal.pasham!
<re_irc> <@n​ihal.pasham:m​> okay.
tokomak has quit [Ping timeout: 240 seconds]
<re_irc> <@n​ihal.pasham:m​> update: In case, anyone finds themselves in a similar situation, I was running an old version of `probe-run`, switching to the latest version fixed the issue. -
GenTooMan has quit [Ping timeout: 250 seconds]
GenTooMan has joined #rust-embedded
fabic has quit [Ping timeout: 252 seconds]
bendem has joined #rust-embedded
<re_irc> <@r​icharddodd:m​> I have a general question about bluetooth. What is the point of advertising services in the adv packet, if the ones provided by the gatt can be different anyways?
<re_irc> <@r​icharddodd:m​> For example, in [the softdevice repo](, an example advertises `1809` (health thermometer) but then in [the...
<re_irc> ... gatt]( uses `180f` (battery). The example seems to work regardless.
<re_irc> <@r​icharddodd:m​> I'm sure I'm missing something.
<re_irc> <@d​irbaio:m​> I think it's so apps can filter before connecting
<re_irc> <@d​irbaio:m​> for example a "thermometers viewer" app could scan, then only show thermometers to you based on the advdata
<re_irc> <@d​irbaio:m​> if you lie and the app connects and then doesn't find the actual thermometer service it might get confused
<re_irc> <@r​icharddodd:m​> So is it a typo in the example? I don't feel knowledgeable enough to say that it is.
<re_irc> <@d​irbaio:m​> not sure whether the spec requires you to not lie.. probably yes?
<re_irc> <@d​irbaio:m​> in that case the example is wrong, yes
<re_irc> <@r​icharddodd:m​> Cool I'll PR.
<re_irc> <@d​irbaio:m​> you can also not advertise the service list at all
<re_irc> <@r​icharddodd:m​> So follow on question: you only have 31 bytes for the advertising data, can you run out of space and not be able to advertise all your services?
<re_irc> <@d​irbaio:m​> 0x03 is "Complete List of 16-bit Service Class UUIDs"... so it's probably required by the spec to be accurate
<re_irc> <@d​irbaio:m​> it's probably not required to be *present*
<re_irc> <@r​icharddodd:m​> I'd look but I hate reading specifications, so I only do it when I absolutely have to.
<re_irc> <@r​icharddodd:m​> Especially ble and usb.
<re_irc> <@r​icharddodd:m​> w3c ones are OK
<re_irc> <@d​irbaio:m​> 🤷‍♂️ I'm afraid I don't know, you'll have to read the spec
<re_irc> <@d​irbaio:m​> here you can see all advdata types
<re_irc> <@d​irbaio:m​> there are also "incomplete" ones, which I guess you're allowed to omit some services from
<re_irc> <@d​irbaio:m​> to check you'll have to read The One True Core Spec
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #rust-embedded
tokomak has joined #rust-embedded