Anyone here into Signal Processing? I'm super interested in the field, and I kinda just wanna see what people think about it, like where the field is heading the future.
I just remembered that I have a 6,000 VDC power supply sitting around.
What do? :v:
[QUOTE=Zero-Point;52854466]I just remembered that I have a 6,000 VDC power supply sitting around.
What do? :v:[/QUOTE]
Capacitors? Spot welding? Ozone?
[QUOTE=andreblue;52855075]Capacitors? Spot welding? Ozone?[/QUOTE]
I don't have capacitors nearly rated for that voltage, nor do I have enough to put in series to stand up to it while still having a decent capacitance.
Spot-welding is high-current low-voltage IIRC.
Ozone... Maybe. It [I]was[/I] originally from an air purifier. Just don't know what I'd use an ozone generator for. :v:
[QUOTE=Zero-Point;52856742]I don't have capacitors nearly rated for that voltage[/QUOTE]
That's what makes it so much fun!
[QUOTE=ben1066;52853357]I have been designing a 5V-200V@15mA boost converter for a Nixie project. It's designed to be operated in discontinuous mode. SMPS_SW will be driven by an STM32's PWM output, SMPS_PWREN should keep the supply to converter switched off until the input is driven low, this is so I can keep to the USB limit of a 470uF capacitive load.
SMPS_SW will be driven at ~50kHz at 3.3V, with a maximum duty cycle of 75%. SMPS_PWREN will be an open collector output, the IO pin used is 5V tolerant.
Do you see any issues with this as it stands? I have simulated it with LTSpice and it appears to perform as expected, but I don't know if I have missed anything.
The FET on the left will probably be a IRLML6402TRPBF (FTDI app note suggested), and the one on the right a BSZ16DN25NS3.[/QUOTE]
The lower transistor on the gate, BC857 isn't doing anything since you don't have a negative rail, you only need the NPN, also I'd have a little gate resistance, maybe 2.2-4.7 ohm just to prevent any oscillation, use 0.5W resistors on the divider to ensure they can withstand the voltage (typically it is fine but might as well), I'd go with a higher voltage switching MOSFET just to provide a little extra margin.
[QUOTE=Zero-Point;52856742]I don't have capacitors nearly rated for that voltage, nor do I have enough to put in series to stand up to it while still having a decent capacitance.
Spot-welding is high-current low-voltage IIRC.
Ozone... Maybe. It [I]was[/I] originally from an air purifier. Just don't know what I'd use an ozone generator for. :v:[/QUOTE]
But the bang is some much fun for underrated caps.
Guys, I'm poor white-trash, I can't afford to be blowin' up no capacitors all willy-nilly.
...Unless...
*plans starting a Twitch stream*
[QUOTE=Chryseus;52857085]The lower transistor on the gate, BC857 isn't doing anything since you don't have a negative rail, you only need the NPN, also I'd have a little gate resistance, maybe 2.2-4.7 ohm just to prevent any oscillation, use 0.5W resistors on the divider to ensure they can withstand the voltage (typically it is fine but might as well), I'd go with a higher voltage switching MOSFET just to provide a little extra margin.[/QUOTE]
Great, thanks. The BC847/BC854 config is more or less straight from an app-note but I'll check to see if I can remove the PNP. I already planned to use 1206 or 1210 resistors for the voltage divider, they are 1/4 and 1/2W respectively, both specced to 200V operational or 400V overload. I might alternatively just use two 0805s in series. I added the 0ohm resistor on the gate as I wasn't sure if oscillation would be an issue, but a low resistance seems sensible. I hope the FET is okay as getting a higher rated one increases cost quite a bit.
Hi guys, I'm doing an assignment which uses single supply op amps which I have literally no experience with. It's supposed to be an oscillator circuit (U1), which generates a square wave, which then drives the L1 diode. D1 then receives the reflected light from L1. C2 should filter out DC and U3 should be a non-inverting amplifier, however, it doesn't work (doesn't amplify anything, as in there is 0V on the output). U4 should be a synchronous demodulator utilizing the square wave from U1, but yet again, it doesn't do shit. U5 should be a comparator with hysteresis, but while it does compare the voltages correctly, there is almost no hysteresis, regardless of the size of R18.
[IMG]https://i.imgur.com/UVR95jJ.png[/IMG]
Thanks for any pointers, after trying and failing at fixing this for several days, I am absolutely clueless.
[QUOTE=Phantoml994;52905508]Thanks for any pointers, after trying and failing at fixing this for several days, I am absolutely clueless.[/QUOTE]
Since this is an assignment I will not give too much help.
Hysteresis requires positive feedback, R18 is giving negative feedback.
There is no resistor on the base of Q3 or Q2.
Using an op-amp follower to provide your virtual ground is preferable to resistive dividers.
Check for correct operation of each section individually.
Look what the cat dragged in!
[t]https://my.mixtape.moe/yjrzpr.jpg[/t]
It even came with the fitting Stepper-Drivers and a controller!
Where can I get a cat like that?
[QUOTE=Leestons;52905919]Where can I get a cat like that?[/QUOTE]
Well, the cat was a former member of our local hackerspace and was moving to the states, so he couldn't take his stuff with him. Luckily I saw him writing in our IRC channel and replied, it's like the third time in the past two years that he tried to give us all his stuff. He basically permanently-loaned us his entire workshop.
Wasn't sure whether to put this in WDYNHW instead but I think someone here's more likely to know stuff about AVRs.
I'm trying to write some code for an ATMega32U4 (specifically [URL="https://www.adafruit.com/product/296"]this board[/URL] at the moment) and a 4x4 switch matrix like you'd see on a mechanical keyboard. The chip enumerates as a MIDI device using LUFA and sends note on/off signals when the switches are pressed. It's basically a midifighter, but using Cherry MX switches instead of arcade buttons.
When I plug it into my computer, and look at the MIDI signals coming in, it seems to be spamming garbage, semi-random (?) data, even when no keys are pressed. It's like the input pins' state is going all over the place for no reason. I unplugged the matrix PCB entirely, and it still does it. If I run my fingers across the pins, even the ISP header and pins that aren't used at all, I can see a noticeable "change" in the garbage data. I'm pretty certain the hardware is not at fault - I flashed QMK onto it (programmable keyboard firmware) and the keys all register fine.
Tried simulating it in Atmel Studio - the 32U4 is annoyingly not supported, but debugging it on a 32 shows nothing wrong with the code that I can see. the key state variable matches what I expect when I mess around with the input pin register.
[URL="https://github.com/fauxpark/fx16"]Here's what I have so far[/URL]. Anyone know what I'm missing? I feel like I must be misunderstanding how these pins work.
Try enabling the internal pull up resistors? Assuming your keys pull low when pressed of course
IIRC you can do this by setting PORTD = 0xF
[QUOTE=Goz3rr;52921504]Try enabling the internal pull up resistors? Assuming your keys pull low when pressed of course
IIRC you can do this by setting PORTD = 0xF[/QUOTE]
I was literally just reading about how you have to do this. Now I feel silly. Cheers :v:
[QUOTE=fauxpark;52921394]Wasn't sure whether to put this in WDYNHW instead but I think someone here's more likely to know stuff about AVRs.
I'm trying to write some code for an ATMega32U4 (specifically [URL="https://www.adafruit.com/product/296"]this board[/URL] at the moment) and a 4x4 switch matrix like you'd see on a mechanical keyboard. The chip enumerates as a MIDI device using LUFA and sends note on/off signals when the switches are pressed. It's basically a midifighter, but using Cherry MX switches instead of arcade buttons.
When I plug it into my computer, and look at the MIDI signals coming in, it seems to be spamming garbage, semi-random (?) data, even when no keys are pressed. It's like the input pins' state is going all over the place for no reason. I unplugged the matrix PCB entirely, and it still does it. If I run my fingers across the pins, even the ISP header and pins that aren't used at all, I can see a noticeable "change" in the garbage data. I'm pretty certain the hardware is not at fault - I flashed QMK onto it (programmable keyboard firmware) and the keys all register fine.
Tried simulating it in Atmel Studio - the 32U4 is annoyingly not supported, but debugging it on a 32 shows nothing wrong with the code that I can see. the key state variable matches what I expect when I mess around with the input pin register.
[URL="https://github.com/fauxpark/fx16"]Here's what I have so far[/URL]. Anyone know what I'm missing? I feel like I must be misunderstanding how these pins work.[/QUOTE]
Everything looks well enough but I'm not to comfy with how you handle the keypad scanning. If I'm reading the keyscan interrupt routine correctly, you only set all the other PORTB pins low instead of turning all the others to Hi-Z. There's a chance you could short out the PORTB pins if two adjacent switches on the same row are pressed at the same time.
[URL="http://noisybox.net/electronics/wingdinger/#firmware"]I found this other project that seems similar to yours[/URL], and try changing your keyscan routine over to it by only setting one PORTB pin at a time to an output (See noisybox's keyscan.c file for the routine they use). Simultaneously it would behoove you to add pull down resistors to all your input PORTD pins from the keypad to keep them in a known state. That's probably why you're still getting garbage data as the pins are floating and picking up charge.
Other than that all the rest of your code looks good but double check that the MIDI USB core works by streaming a constant note every few seconds or so instead of from the keypad. :words:
Edit:
What Gozz3r said.
[QUOTE=LoneWolf_Recon;52921530]Everything looks well enough but I'm not to comfy with how you handle the keypad scanning. If I'm reading the keyscan interrupt routine correctly, you only set all the other PORTB pins low instead of turning all the others to Hi-Z. There's a chance you could short out the PORTB pins if two adjacent switches on the same row are pressed at the same time.
[URL="http://noisybox.net/electronics/wingdinger/#firmware"]I found this other project that seems similar to yours[/URL], and try changing your keyscan routine over to it by only setting one PORTB pin at a time to an output (See noisybox's keyscan.c file for the routine they use). Simultaneously it would behoove you to add pull down resistors to all your input PORTD pins from the keypad to keep them in a known state. That's probably why you're still getting garbage data as the pins are floating and picking up charge.
Other than that all the rest of your code looks good but double check that the MIDI USB core works by streaming a constant note every few seconds or so instead of from the keypad. :words:
Edit:
What Gozz3r said.[/QUOTE]
Okay, I've changed the middle section of key_setup() to just set PORTB and PORTD to 0x0F, and the loop in the interrupt now looks like this:
[code]for(uint8_t i = 0; i < MATRIX_COLS; i++) {
DDRB &= ~0x0F;
PORTB = (PORTB | 0x0F) ^ _BV(i);
DDRB = _BV(i);
state |= (PIND & 0x0F) << (4 * i);
}[/code]
I'm not getting the floating garbage anymore, so that's good, but neither are the keys generating any actual signals. In the simulator, if I set PORTD to 0x09, the debounce buffer fills up with 0x9999 as I expect. PINB is always 0, and when a bit in DDRB is 1 the same bit in PORTB is 0.
The LUFA stuff I'm pretty sure is fine. Thought I might have fried the pins but I threw QMK onto it again and there were no problems typing with it.
The text box is empty when I go to edit, even on chrome, so apologies for the double post. Maybe it'll merge?
Anyway, I got it working with this:
[code]
// in key_setup()
PORTB = 0x0F;
PORTD = 0x0F;
sei();
// in ISR
for(uint8_t i = 0; i < MATRIX_COLS; i++) {
DDRD = _BV(i);
PORTD = ~_BV(i) & 0x0F;
state |= (PINB & 0x0F) << (4 * i);
}[/code]
paging AVR wizards
I've got a Mega328P-AU and an FT231x that won't talk to each other. I'm using the standard arduino serial library and it's in theory wired correctly (TX/RX wired to PD0/1 on the atmel chip) but for whatever reason it's acting up. Nothing is getting to or from the arduino despite the FT231 working just fine on its own. Resistance on the traces checks out fine so it's not a physical connection issue as far as I can tell.
I'm stumped. I'm wondering if there's some fuse I need to burn or a different bootloader required for the AU chip to get the UART to work properly.
Here's the circuit for reference. Not exactly super complicated.
[img]https://i.imgur.com/W2FZZNI.png[/img]
Are you sure your baudrate is set/calculated correctly? Is your avr running at the correct frequency? Usually you have to tell the serial library you're using at which frequency you're running to correctly calculate the baudrate. You can check this by letting an LED blink with the frequency of 1Hz and seeing if it is actually running at 1Hz.
Yep, I've done a standard blinkenlight program and it's got the correct frequency as far as I can tell.
I've noticed that the RXLED on the FTDI chip never lights up, meaning that the chip isn't ever getting a signal from the AVR. That would normally (in my opinion at least) indicate either bad configuration on the AVR or a physical issue of some kind. I've verified that the traces do physically have good connection so it's either internal damage to the chip or something else I can't think of.
[editline]30th November 2017[/editline]
FUCK it was a bad solder joint. Turns out even though the 328p looked like it was soldered fine, a few pins including the tx/rx lines weren't making good contact.
:suicide:
short the TX and RX of the FTDI together, then it should loop back whatever you write to it. That way you can check if the FTDI itself works.
I'm having some trouble in making a calculator, probably because my logic approach is wrong. Can anyone lend a hand?
I'm having issues with my dividing portion of the calculator. I've implemented the rest easily, and I want to try to make the multiplier circuit behave as a divider similar to how I converted the adder into a subtractor by turning the second input negative ( "subtract" bit goes in, inverts all, adds 1 )
Is it possible to do it with a multiplier having a "divide" bit? I know dividers use subtractors which is why I thought I'd be able to just turn all the adders into subtractors, but that's not really working out
Here is a 2x2 version of the multiplier circuit I'm using:
[img]https://upload.wikimedia.org/wikipedia/en/7/7b/Binary_multi1.jpg[/img]
All help appreciated
:snip:
I'd say neopixels only because EL is more difficult to work with, and if you're not careful you might end up with coil whine on your inverter that will drive you mental. If you found a way to diffuse the pixels through some sort of opaque plastic it'd probably look not half bad. Plus like you said neopixels will give you a lot more flexibility in design.
[editline]13th December 2017[/editline]
lol okay snipped but why, it was a good question
I've fixed the op up so it should be readable now.
Mhm, new forum smell
Hey I gotsa question. My boss gave me an xbone controller that doesn't work right, and I want to use the analog sticks, triggers, and buttons in a portable Pi project. Thing is, I dunno how to read all the many many pins that the various analog devices use. The joysticks have 8 pins each (3 for each axis + 2 for the click button), while the analog triggers have 3 each. I'm not sure if I should use an arduino to read them or not, as any 'duino with enough pins seems like it'd be way too big for my project concept.
Sorry, you need to Log In to post a reply to this thread.
Electrical Engineering V3
