Search the Community
Showing results for tags 'schematic'.
Found 3 results
I will probably switch to using a micro, but getting something working, without one, should help me with writing the code. I record concerts, and recently switched from recording into a laptop to a multi channel recorder. While I have used worse, the deck's meter is lacking, compared to the software one I am used to. One reason for building this is to get more resolution, the only markings are at -18dB (?) and 0dB. Also, there is no peak hold, so unless I am looking at it, when a spike happens, I do not know how close it came to clipping. In addition, I also want to add a clip indicator, as I have found the one in the deck to be unreliable. I ran into this the other day, which got me thinking about this project. This would also give me better visibility. I looked at a couple chips, and the LM3915 seems to be the best fit for this project. For the most part, all the examples I have found are for "dancing lights" which might be nice to look at, but not of much use for my purposes. The base, "dancing lights", part is pretty straight forward. The peak hold and clip indicator are where I hit a snag. Doubling up the LM3915 and using one in dot mode, for the hold, seemed like a good idea at first, but not so good the more I think about it. I found one explanation of switching between bar and dot mode to achieve the hold, but without a schematic to reference it is hard for me to follow. Ideally, I would like the peaks to stay lit, as opposed to falling off, as is normal. Thinking about it more, an extended hold time would be a better option. That brings me to the last problem of the clip indicator. That is easy enough to light, but needs to stay lit, until reset. This is the meter I am used to, and what I am trying to somewhat emulate. The inner bars are the VU meter, but it is the outer, peak meter I want. The values to the right are what I was thinking about with making the peak hold persistent. While I will not be able to go get a beer and come back to see that I was coming close, and should probably turn down, I would like to be able to see how high it got after I hear a spike in volume, or crowd noise. A simple clip indicator will be good enough to warn me of problems. Now that I explained my goal good enough, I hope, on to what I have so far. The recorder runs on 12V DC, so I figure sharing a battery would be the best power solution. If this ends up too power hungry, I bring spares, so I can a separate one if I have to. I will need to come up with a way to drop the voltage, for the LEDs, but that can wait for now. The second LM3915 can be ignored, I just did not delete it yet. The rest is mostly taken from the datasheet, so should be OK, except deciding on values and what not. The 5V for the LEDs is just an arbitrary number to fit the requirements; 3V < > Vcc. What I need to figure out first is how to do the switching between bar and dot mode. The circuit theory, from the meter kit, linked above, uses a transistor, nand gates, op amps, and bilateral switches to do this. While I can sort of understand how each works on its own, I am lost when it comes to putting then together. If someone could help me with that part of the circuit, it does not have to be a direct fit, just something similar, it would be a great help.
Hello, I am looking for a working Eagle library for the CC1310F64RHBT. I am not experienced with creating .lbr files for Eagle, but after some googling I have produced a rough one which is based on a conversion from the Ultra Librarian .bxl format. If anyone has a working library that they already use, it would be super helpful if they could share it with me. Taking a look at the library attached below which I have produced and confirming that the SMD footprint will work would be super helpful. Thanks, Cameron CC1310F64RHB.lbr
I'm learning to read schematics. I noticed that the original Launchpad's target-socket schematic (slau318d, page20) doesn't show the ground pin running to the ground symbol like other grounded lines. Is that implied? If so, why is the VCC pin explicitly running to VCC? Thanks!