|
I have been down that rabbithole, and you will absolutely not find a slip ring rated for anything close to what you need. Everyone uses a battery on the rotor. One thing I experimented with, and seems to be viable, is to use one motor on the stator, spinning the rotor, and another motor on the rotor, acting as a generator. I used a BLDC and a three phase rectifier, and it was pretty decent. Never ended up doing the mechanical design, though.
|
#
?
Aug 22, 2020 06:22
|
|
|
|
| # ? Jun 4, 2024 12:13 |
|
|
I'm not sure I follow how the motor-generator version would work. The base spins a shaft, but if the shaft isn't turning relative to the prop, how do you generate a current on that side? Might be possible to slop together a good enough rotary transformer from two halves of a pot transformer facing each other. That's basically how a real high RPM wireless slip ring works, just can't find a premade one for not expensive
|
|
#
?
Aug 22, 2020 07:03
|
|
|
Foxfire_ posted:I'm not sure I follow how the motor-generator version would work. The base spins a shaft, but if the shaft isn't turning relative to the prop, how do you generate a current on that side? You could mount the whole spinny armature thing on the first motor, then mount the generator motor a little bit off-center with a gear or rubber wheel that engages with a stationary thing on the non-moving part
|
|
#
?
Aug 22, 2020 10:14
|
|
|
Intentionally loving with the rotor's center of gravity sounds sketchy. I'd go for inductive charging (think of an electric toothbrush). Or you could just stick a couple strong magnets on the stator and some pickup windings on the rotor. As the rotorn spins up you could just passively rectify the induced emf.
|
|
#
?
Aug 22, 2020 13:43
|
|
|
A bad idea that works on paper might be to use AC and induce a current that way. Battery in the moving part seems cleanest. You'd need all the smarts there anyway to do the light patterns, because even if you find a way to pass power, that's a lot of data. And you probably want a predictable way to power that on and off, rather than only be powered while spinning.
|
|
#
?
Aug 22, 2020 13:59
|
|
|
Battery on the prop is more spinning mass though. Microcontroller, LEDs, and power electronics are a lot lighter than a battery. Little coin cells seem like they don't have the capacity or discharge rate to support a lot of bright LEDs This KnifeWrench posted:A bad idea that works on paper might be to use AC and induce a current that way. Thinking something like this  where everything is rotationally symmetric around the blue motor shaft and purple/green are the wires on the transformer primary/secondary. The diagonal gray blocks would be cores intended for a pot transformer:  It should transfer AC regardless of if it's spinning or not, it just might be really inefficient if the gap is too big and lots of magnetic flux leaks without going through the other coil. e: I hosed up my drawing and that lower right block should be diagonals the other way e2: Digikey's wireless charging coils (which is the same thing, just without the halves spinning) category has prewound ones Foxfire_ fucked around with this message at 19:52 on Aug 22, 2020 |
|
#
?
Aug 22, 2020 19:32
|
|
|
KnifeWrench posted:A bad idea that works on paper might be to use AC and induce a current that way.
|
|
#
?
Aug 22, 2020 19:48
|
|
|
I'm fundamentally missing how a TRS connector with a carbon brush block on either side can't get you power/ground/data at high rpm. I've seen that setup work at up to brushless DC motor fan speeds, which is like, what, 3k rpm? 2k? Clearly you put a microcontroller in the hub to drive the LED string, but with a big cap on the power rails and a fairly low bitrate to tell the micro in the hub what image to display next, I think something super cheap like that would work.
|
|
#
?
Aug 22, 2020 21:26
|
|
|
That's a traditional slip ring. All the commercial one's I've found are rated for 600RPM at most, and ante's saying that when they looked in the past they didn't find anything for higher speeds either. Are the things you've seen off-the-shelf or homemade and how fragile were they? Other feasibility napkin math: - Desk fans seem to spin at 1200 to 2000 rpm, call it 2000rpm / ~33Hz. A DC gearmotor for that speed is easy to find at reasonable torque - A 5mm arc at the end of a 150mm radius rotor is an angular resolution of about 2 degrees, can also find motors with built-in encoders that good easily. - A 150mm radius rotor at 2000rpm has a linear speed of about 30m/s at the end - A 5mm localization requires a 150us pulse. That's easily within a LED circuit's switching speed, but rules out stuff like neopixel strings. Gonna be timer hungry, maybe wants a little FPGA to do the timing. Foxfire_ fucked around with this message at 22:30 on Aug 22, 2020 |
|
#
?
Aug 22, 2020 22:16
|
|
|
I have an old Nook HD+ tablet with a bad battery that I'm considering saving for future projects since it's got a really nice screen. Stock it uses a 3.7v li-po battery which is expensive to replace - is there any reason I couldn't just get a battery controller designed for 18650 Li-ion cells and feed the output from that into the tablet at the Vbatt test points instead? Obviously it wouldn't be as compact but for the uses I'm thinking of that's not a big deal.
|
|
#
?
Aug 23, 2020 01:05
|
|
|
You're over complicating. Any standard lipo, including an 18650 should work fine with no fussing over extra stuff. Obviously there's a big asterisk there, because none of us have examined the schematic or software
|
|
#
?
Aug 23, 2020 01:51
|
|
|
Only thing I can think of is if the test points are on tiny traces since they'd normally have no current flow.
|
|
#
?
Aug 23, 2020 01:51
|
|
|
ante posted:You're over complicating. Any standard lipo, including an 18650 should work fine with no fussing over extra stuff. Oh dang, I figured using raw Li-ion 18650 cells instead of an assembled battery needed separate protection circuitry to prevent over-discharge and such, since afaict that's built into most lipo batteries. Foxfire_ posted:Only thing I can think of is if the test points are on tiny traces since they'd normally have no current flow. They're fairly big pads right under the connector but I could always just desolder the connector and go straight in that way too. corgski fucked around with this message at 01:59 on Aug 23, 2020 |
|
#
?
Aug 23, 2020 01:57
|
|
|
Are you sure you can't get a compatible replacement pack for cheap off AliExpress or something? I found one for my obscure Chinese tablet so this could be possible.
|
|
#
?
Aug 23, 2020 06:11
|
|
|
Anyone have any experience using a HD107S addressable LED before (whether they are crappy or actually meet their claimed specs)? It's a knock-off APA102 / DotStar with a faster PWM and data rate + the update synchronization part of the protocol fixed. My other idea for getting fast enough update rates for a 30Hz rotation rate is using normal RGB LEDs and having a ATTiny214 (6 timers, enough GPIO current) for each pair of LEDs. Basically reimplementing the control scheme for a APA102 strip with a faster PWM rate and stripping out the extraneous parts of the serial protocol. Central FPGA would also work, but 3 fast PWMs per LED is a lot of IO to route a long way.
|
|
#
?
Aug 24, 2020 00:32
|
|
|
mobby_6kl posted:Are you sure you can't get a compatible replacement pack for cheap off AliExpress or something? I found one for my obscure Chinese tablet so this could be possible. For like $30-40 with no guarantee of quality  If it was closer to $10 I'd be doing that.
|
|
#
?
Aug 24, 2020 00:55
|
|
|
In a bidding war for a used Cricut Max because my girlfriend made passing reference to vinyl stickers and it seems like I can use it for paste stencils for SMD stuff, right?
|
|
#
?
Aug 24, 2020 03:25
|
|
|
Yeah, I've heard that
|
|
#
?
Aug 24, 2020 03:37
|
|
|
In this paper, they cascade a buck converter onto a Luo converter and claim that it turns a high voltage low current output supply into a high voltage high current supply, but I don't understand why that would happen. What limitation of the Luo converter is being corrected by the buck? https://pdfs.semanticscholar.org/ceab/c83d0811adc447bc173ab5eb889c7ec03088.pdf
|
|
#
?
Aug 25, 2020 21:00
|
|
|
taqueso posted:In this paper, they cascade a buck converter onto a Luo converter and claim that it turns a high voltage low current output supply into a high voltage high current supply, but I don't understand why that would happen. What limitation of the Luo converter is being corrected by the buck? The output is 11V vs 100V for the Luo alone. I don't know what point they're trying to make, but it doesn't seem like a very good paper. Bucks are good at delivering continuous output current without big capacitors, though, because at a high enough load the inductor continuously conducts current into the load, unlike, say, a buck where it alternates between delivering current to the load and ground. Stack Machine fucked around with this message at 01:11 on Aug 26, 2020 |
|
#
?
Aug 26, 2020 00:56
|
|
|
Is table 4 a typo maybe? Or maybe I don't understand what that table means Using a super lift converter to get good efficiency with low solar cell voltage, followed by a buck makes sense but it seems not particularly clever if you are already looking at superlift converters for solar plus battery. taqueso fucked around with this message at 02:04 on Aug 26, 2020 |
|
#
?
Aug 26, 2020 02:00
|
|
|
taqueso posted:Is table 4 a typo maybe? Or maybe I don't understand what that table means I'm not sure either. "Voltage stress" is listed as 120 but all of the other plots related to that topology show 11 as Vout. This is definitely not the best way to get 12V out of solar panels though, so all I can guess is those are the typos, since 120VDC is possibly a reasonable thing to run, say, power tools and lighting on. The article mentions rural India, though, and I thought most appliances there were 240V.
|
|
#
?
Aug 26, 2020 03:28
|
|
|
Hey, dunno whether there's anybody in here who can help me, but I have couple of questions that I haven't had a ton of luck finding info about. For an ATmega32U4, does it matter much what bootloader I use to run code on it? The reason I'm asking is because I recently put together one of these:  For some context, that's a board that runs this ATmega32U4 code to adapt a Microsoft Sidewinder 3D Pro joystick to USB. The thing uses a digital protocol that involves the MIDI lines of the gameport, so normal gameport-to-USB adaptors don't work with it. The adaptor works great, but I'd like to design a board that has all the parts (except for the ports, unless there's an option for that, too) surface-mounted, so I can have a PCB house do most of the work by sending them the layout, a BOM, and placement data. That means eliminating the Teensy and re-implementing a lot of it on the board itself. Given that there's a schematic of the Teensy available, that should be simple enough, but the bootloader it comes with (Halfkay) is proprietary. So, is it likely to work if I use something like LUFA for the bootloader and flashed the same hex to it? The other question I had is, is there a good intro-to-KiCad thing available anywhere? I downloaded Fritzing to make a board for the above schematic since it seemed to be really straightforward to use, but the board I laid out and had manufactured looks super amateurish, partly because I was running into what seemed to be limitations with it. But, hey, on the upside, I went from installing it to having Gerbers sent off for manufacturing in like four hours, and the board I laid out works great. However, looking for something more capable which runs on a Mac, isn't locked to a particular PCB manufacturer, and is free didn't come up with much other than Eagle and KiCad. And, well, both of them look like they have a steeper learning curve. But, if I need to go with one of them, I'd rather it be the open-source application.
|
|
#
?
Aug 26, 2020 05:22
|
|
|
That board has a physically separate microcontroller that is never normally reprogrammed. Pushing the program button causes it to erase the main microcontroller flash, then make the main microcontroller run a loader program instead. That loader program talks to your laptop over USB, receives your program, and writes it into the main microcontroller flash. If you have some other means of programming the main microcontroller, you can completely ignore that load coprocessor and not populate it. But if you just cloned everything as-is, it won't do anything because neither microcontroller will have any software to start with. If you are making a PCB anyway, you should pull the JTAG/SWD pins out into a connector and use a normal programmer.
|
|
#
?
Aug 26, 2020 05:50
|
|
|
Foxfire_ posted:That board has a physically separate microcontroller that is never normally reprogrammed. Pushing the program button causes it to erase the main microcontroller flash, then make the main microcontroller run a loader program instead. That loader program talks to your laptop over USB, receives your program, and writes it into the main microcontroller flash. I was figuring I'd need to break out the programming pins to at least write the bootloader, yeah. I didn't think the Teensy 2.0 had a separate microcontroller, though (it's not listed on the schematic, anyway, and I don't see it on my board). I thought that was just on later revisions. Anyway, if I can write the program directly to the microcontroller without bothering with a bootloader and have it just work, that'd solve that problem. Sounds like that might be an option?
|
|
#
?
Aug 26, 2020 07:24
|
|
|
Kreeblah posted:Anyway, if I can write the program directly to the microcontroller without bothering with a bootloader and have it just work, that'd solve that problem. Sounds like that might be an option? You only really need a bootloader if you don't have a normal programmer available, or you want to do something fancy like update firmware in the field over USB or whatever. They're used with arduinos a lot because the whole point of arduinos is you just plug em' in and go and don't need to fiddle with a programmer, but if you have a programmer then who cares. I almost never use one for my projects since I know I'll always have a programmer handy to rewrite it if I need to since I have like 20 of the drat things 
|
|
#
?
Aug 26, 2020 07:28
|
|
|
Kreeblah posted:I was figuring I'd need to break out the programming pins to at least write the bootloader, yeah. I didn't think the Teensy 2.0 had a separate microcontroller, though (it's not listed on the schematic, anyway, and I don't see it on my board). I thought that was just on later revisions. I didn't see the 2.0 when I looked on your schematic. If you have real programmer access, there's no need for the software to be able to program itself.
|
|
#
?
Aug 26, 2020 07:50
|
|
|
Shame Boy posted:You only really need a bootloader if you don't have a normal programmer available, or you want to do something fancy like update firmware in the field over USB or whatever. They're used with arduinos a lot because the whole point of arduinos is you just plug em' in and go and don't need to fiddle with a programmer, but if you have a programmer then who cares. I almost never use one for my projects since I know I'll always have a programmer handy to rewrite it if I need to since I have like 20 of the drat things OK, cool. That makes things way simpler. Now I just need to figure out KiCad.
|
|
#
?
Aug 26, 2020 08:14
|
|
|
taqueso posted:In this paper, they cascade a buck converter onto a Luo converter and claim that it turns a high voltage low current output supply into a high voltage high current supply, but I don't understand why that would happen. What limitation of the Luo converter is being corrected by the buck? This paper is a mess. Hard to tell how much of it is honest typos vs the authors literally not knowing what they're talking about. IMO using multisim for any publication is generally a huge red flag that says "I'm an undergrad and my professor is making me submit this abstract for a grade." ANIME AKBAR fucked around with this message at 14:37 on Aug 26, 2020 |
|
#
?
Aug 26, 2020 13:44
|
|
|
Kreeblah posted:OK, cool. That makes things way simpler. Now I just need to figure out KiCad. Dominoes fucked around with this message at 00:14 on Aug 27, 2020 |
|
#
?
Aug 27, 2020 00:11
|
|
|
Kreeblah posted:
What about designing a board with all the extras that you want, and just lay out some through holes for the entire Teensy to piggy back on it? Just treat it as another component. Or like an Arduino shield.
|
|
#
?
Aug 27, 2020 02:36
|
|
|
One Legged Ninja posted:What about designing a board with all the extras that you want, and just lay out some through holes for the entire Teensy to piggy back on it? Just treat it as another component. Or like an Arduino shield. That's what I did with the board I did in Fritzing, and it works just fine. I'm looking at this as a good opportunity to get some experience doing something new, though, and I'm hoping to end up with something I can put up on GitHub for folks to send out to be produced. When I started looking for these, I found a few people who had produced PCBs, but the only publicly-posted ones I was able to find are old revisions using a different microcontroller. Meanwhile, the two people selling them either have a huge waiting list or don't ship to the US.
|
|
#
?
Aug 27, 2020 03:27
|
|
|
Kreeblah posted:I'm looking at this as a good opportunity to get some experience doing something new, though, Fair enough. As good a reason to do something as any.
|
|
#
?
Aug 27, 2020 03:40
|
|
|
Dominoes posted:Compared to most programs you'd want a tutorial for, KiCad (And Eagle, for that matter) is straightfwd, due to its confined feature set. I bet you can figure it out from experimenting. Start with the schematic editor, using nets (green lines), components, and labels. Then try converting to a PCB, and see how far you can get with traces, vias, filled areas, and a bit of board setup. The library system can be confusing, so post if you have questions, eg relating footprints to to symbols, or creating your own. Look up shortcuts later as required, or things like customizing fill parameters, DRC conditions etc. You're right. Poking at KiCad isn't as bad as I first thought. At least, from the schematic perspective, anyway.  I guess the next step is to figure out how to assign footprints to these things in a way which doesn't make KiCad crash (or wait until they fix the bugs I filed for the footprint assignment crashes).
|
|
#
?
Aug 27, 2020 20:36
|
|
|
Spend some time browsing the footprint library. Most standard packages will have footprints included. (I find myself needing custom symbols much more often). Press E while mousing over a symbol in the schem editor, and select your footprint in the appropriate table row. Note that you can search in the main fp browser, but not here; you have to know the category. You may also wish to use this table to specify part bums, for your own accounting, or for generating a BOM for SMT assembly houses. Footprints and symbols are independent in KiCad, which isn't how most editors work. I love it, but this isn't a universal opinion. Linky to the bug? I haven't experienced it personally. The main tech trouble I get is after changing directory structure. Dominoes fucked around with this message at 21:04 on Aug 27, 2020 |
|
#
?
Aug 27, 2020 21:01
|
|
|
If you go Preferences -> Manage Symbol Libraries in Eeschema and start turning stuff off, is it some particular library that's pissing it off?
|
|
#
?
Aug 27, 2020 21:09
|
|
|
It's specific to the Mac build. It's failing to make a selector call (the objective C equivalent of a function pointer) whenever I try to open the footprint assignment tool in Eeschema. It doesn't matter whether I'm doing it from the tools menu for the whole project, or clicking the book icon on the footprint for a specific part. It crashes in all of those scenarios. https://gitlab.com/kicad/code/kicad/-/issues/5389
|
|
#
?
Aug 27, 2020 21:24
|
|
|
Kreeblah posted:It's specific to the Mac build. It's failing to make a selector call (the objective C equivalent of a function pointer) whenever I try to open the footprint assignment tool in Eeschema. It doesn't matter whether I'm doing it from the tools menu for the whole project, or clicking the book icon on the footprint for a specific part. It crashes in all of those scenarios. I use the mac version and I don't have that problem, weird. I guess I haven't updated in a little while, maybe it's a new bug. Their mac support has always been kinda rocky at best unfortunately but I thought it was getting better  e: Nope we're using the same version, hm. Shame Boy fucked around with this message at 21:51 on Aug 27, 2020 |
|
#
?
Aug 27, 2020 21:49
|
|
|
Shame Boy posted:I use the mac version and I don't have that problem, weird. I guess I haven't updated in a little while, maybe it's a new bug. Their mac support has always been kinda rocky at best unfortunately but I thought it was getting better Hmmm. What version are you on? Maybe I can try downgrading and see whether it still happens. Edit: Welp.
|
|
#
?
Aug 27, 2020 21:52
|
|
|
|
| # ? Jun 4, 2024 12:13 |
|
|
Kreeblah posted:Hmmm. What version are you on? Maybe I can try downgrading and see whether it still happens. We are using slightly different OS versions though, you're on 10.15.6 while I'm 10.15.5. Only thing I can think of off the top of my head is your stacktrace seems to indicate it was trying to init Python when it crashed: code:
|
|
#
?
Aug 27, 2020 22:02
|
|