I hate it when a bunch of nice people help out someone who asks a question on a forum, then the person who asked the question doesn't let the other people know how it turned out! Very sorry about that guys, my bad. Here is what happened:
Since I foolishly got PCB's made from Seeed before verifying the circuit , I had the fun job of tearing up some 8 mil traces in a very dense part of my board, and doing a little last minute routing. A well deserved punishment for my haphazard development strategy. A few days went by of trying different resistors and capacitors in the circuit, and during this time, I ran this problem by some experts I know. One of them pointed out that a PWM signal is preferable to an analog signal in my circuit.
The device I was designing is meant to control electromagnets on three axes for science-y purposes (the customer was the Physics Research Department at The Ohio State University. They do a bunch of complicated physics stuff I don't understand with my device.) The device (called Lodestone... get it?) controls the three sets of electromagnets with three MOSFET H-bridges. I wanted to output a constant current, therefore I thought it would be a good idea to operate the MOSFETs in the linear region. Alas, as my MOSFET expert pointed out, I'd have a beastly amount of power dissapation in my FETs (the magnets are meant to be run at 20V and up to 10A). I learned that I should do my best to stay out of the linear region, and stay in the off and saturation regions.
Anyway, I abandon the effort to make a decent analog voltage with PWM, took out the caps, and just ran PWM into my MOSFETs. The end result worked surprisingly well, and due to the inductance of the electromagnets (I think), you can't even tell they are being switched on and off. It maintains a steady current through the magnets.
So I know what you're thinking: "Destate9, if you would have told us that you were running this signal into a MOSFET H-bridge, we would have told you that was a stupid idea!" So yeah, probably should of told y'all more about the circuit. Lots of things learned with this project. I'll be sure to post the schematic, layout, case, pictures, and general story elsewhere in the forum. Thanks so much to everyone that helped! I'm never going to make a PWM to analog circuit without a series resistor ever again!
So since I'm running a 40MHz clock, with a period of 65535, that is 610 Hz, so an RC filter with a 330uF capacitor and a corner frequency of 61 Hz requires an 8.2 ohm capacitor. I added one in series between the GPIO pin and the cap, and measured the voltage at the positive terminal at the cap. An improvement, but I still don't know if this will be accurate enough for my application (new configuration in red). Any idea where I could find the equation to characterize this behavior?
So I've been trying to make a constant current H-bridge circuit for a project, and I'm running into trouble with PWM. Right now, all I have connected to the Output compare pin of my PIC32MX microcontroller is a 330uF capacitor (Max ESR of 1.4 ohms according to datasheet). I assumed a 50% duty cycle (at VCC = 3.3V) would yield 1.65V, but that is not the case. As you can see in my attached picture, the output voltage (y-axis) vs Duty Cycle (divide the x-axis by 65535) looks a little more like a CDF. I know there must be a way to calculate this function based on the capacitor charging and discharging, but I've been scratching my head for a while, and was wondering if anyone else has derived this function.
The Ohio State University Formula Car Team used MCP2551 CAN transceivers all last year, and we've had a lot problems with them. I know you're probably not going to use these in an automotive setting like we did, but we found they are extremely sensitive to small transients. We probably went through 20 chips last year, spent many hours on the phone with Microchip, and reached the conclusion that they are just very sensitive ICs. Microchip, however said that they were coming out with a new IC mid-2013 to replace the MCP2551, the MCP2561/2. I HIGHLY recommend you get yourself a MCP2562 instead of the MCP2551, because a good chunk of my life for the past year has been wasted due to grief from the sensitive MCP2551.
Yo, I'm trying to make a PIC based board that will switch a relay when it receives a voice command. The relay will switch house lights on and off. So basically, this will be like the clapper, only I'm hoping the command input will be complicated enough so it won't be triggered by knocking or general hubbub. I know there is a speech recognition library for the dsPIC, but I want to keep it relevantly simple.
Our ECU controls the ignition during the shift. We tap the switching pin of the paddle input of PICShift to send in the raw rising edges of the paddles to the ECU, and in v2 we will have dedicated pins for that so we don't have to have two wires in one spot.
As for the code, it was my first time coding a PIC, so I only had some bits of code from the forums to go off of, so it's not great. I have an unnecessary config header and c file, and a pretty inconsistent coding style. Since then, I've done a couple of PIC projects, so I know have a more developed style, and a better understanding of header files. At the moment, the only special feature we have is a cooldown (a fail safe to avoid the shifter switching too many times too fast. It will lockout the board until reset), and allowing the driver to upshift while the downshift paddle is still held after the command is executed, and vice versa. Anywho, excuse the sloppy coding style, and this is just the first pass at PICShift, so not all the special features are implemented yet.
Thanks, dude! And I never thought of using DIP switches, that would totally take care of the vibration problem. However, there are a few reasons why we went with the PIC that I didn't mention in the original post. Partly because we wanted to have some special features on the board (such as not letting an upshift and downshift command interfere), not letting shift commands happen faster than the engine can handle, and v2 will have an extra IO to take in RPM data from the ECU so we can play around with a pseudo-automatic transmission. Really, I'm diggin the PIC because of our ability to update the board with simple firmware patches. Also, after reading this site for about a month I just couldn't wait to do something with a PIC, so there's that.
Also, I welcome any critiques, I'm looking to improve my design skills and this is probably the best place to get advice from pro hackers!
Here is a board with the 50x31 Sick of Beige case.
This board uses a 6-pin PIC (PIC10F322) to generate a pulse of an exact length from the rising edge of a button. This is going on The Ohio State University's formula car (http://www.formulabuckeyes.com/), and will actuate our pneumatic shifters. Originally we used a monostable 555 circuit to generate the pulse, but we wanted something we could program different times into rather than adjusting a potentiometer. Also, since this is going on a formula car with a lot of vibrations, we try and avoid potentiometers when we can.
Here are some more pics of the board:
(Those are the MOSFETs we use to switch power for the pistons on the back)
(5V section of the board to the left of the divide, 12V section to the right)
(Schematic of the board. Pretty simple stuff, except using the ICSP header and 4 IO can be a bit challenging on a 6 pin PIC. I also had to be sure no one could mess up and send erratic signals to the shifters, potentially damaging the system. Notice that DAT and CLK can't be connected while the MOSFETs are connected)
This was my first project involving polygons, PIC, Sick of Beige, and Eagle (although I have used NI multisim). So all and all this was a really interesting learning experience.
Big shout out to Ian for the advice/support! Also, this being my first PIC project, this site was incredibly helpful, so a big thank you to all you forum people as well! Finally, although we will be switching to Seeed, Laen has been an awesome PCB service. So thanks, Laen!
So I'm working with the Ohio State University formula team (http://www.formulabuckeyes.com/) on a new shift display for our car, and we want to use SMD LEDs. We are going to send the board serial data, which will be received by some sort of constant current LED sink driver IC like the TLC5916. The end result of this board will be a SMD LED matrix meter that will tell the driver when it's time to shift based of RPM data from our ECU.
I'm wondering what size/spacing is practical for the LEDs. What was used on the latest Dangerous Prototypes badge? I want it to be compact, but I still want some of our new guys to be able to solder them together. Immediately I thought of the badge, but I can't find any info on it.
Yo, first of all, good call on that VUSB and barrel connector thing, Arhi. Beat me to it, but for me, that brings up a concern about J2. Is that a connector to put 5V in or 7-15V? I thought it was the latter, and if so, shouldn't that be connected to the same net as the barrel connector as opposed to VUSB? I believe Arhi already mentioned this when he said:
"It's better to connect VUSB to one side of J6 and barrel (+J2) directly to Vreg1 that's connected to other side of J6."
Also, I've always wanted to use that third pin on a barrel connector for something, but I've never had the opportunity. Wouldn't it be cool if you had some sort of MOSFET's gate (p-channel) hooked up to that middle pin of the barrel connector, then pull it up. Finally, the source connected to J2 (positive pin) and the drain connected to the positive pin of the barrel connector (maybe with a diode or something). MOSFET would switch J2 so when no barrel connector was in it would allow voltage from J2, but when a barrel connector is plugged in it cuts off J2.
Anyway, I'm just spit ballin, it's not a complete idea. It's 2:30 in the morning and I'm on here to procrastinate studying for an exam, so forgive me if my ideas are nonsense. I've just always wanted to see that little switch thing in barrel connectors get used because I thought it was the coolest thing when I learned that was an actual switch, and then I subsequently got real salty when I noticed that it's actually a pretty useless/unused feature.
Yo, I'm in my first PIC project, and I'm using a 6 pin PIC10F322 with the XC8 compiler. I'm trying to put in some ms delays but when I use the command "__delay_ms(10);" it gives me the error "Unable to resolve identifier __delay_ms()." I've been checking online, and I've seen people claim that it is a bug in the compiler, or even with MPLABX. It will compile, but it still shows up red. It's one of those things that I can put up with, but I'd like it to go away (like Ke$ha).
Also, when I try to configure the configuration bits ("__CONFIG(WRT=OFF);" for example) it gives me a relocation error and I have to comment them out. What is the traditional way to configure bits with XC8?
Finally, quick question: What is the difference between using "" with #include and using <> with #include?