Jump to content
43oh

mbeals

Members
  • Content Count

    347
  • Joined

  • Last visited

Reputation Activity

  1. Like
    mbeals got a reaction from spirilis in 6pin connector for SpyBiWire+Serial?   
    I used tag-connect for the PIC projects I've done in the past and I really like them.  The pic connector is 6 pin, so all you need to do is make up a simple adaptor with the .05" ez430 header on one side and an rj45 for the tag connect cable on the other.  A while back I drew up a set of boards to do just this, as well as adapt .05" to .1" and adapt the ez430 format to a similar format that lacks mirror symmetry (otherwise it is easy to reverse the polarity).  I've been meaning to get them printed up and built, just haven't done it yet.
     
    Also... here are some female-female, 6 conductor cables in both .1" and .05" pitch:
    http://www.digikey.com/product-search/en?pv31=241&pv88=7&pv89=2&pv89=1&FV=fff40018%2Cfff80232&mnonly=0&newproducts=0&ColumnSort=0&page=1&quantity=0&ptm=0&fid=0&pageSize=25
     
     
    The one downside to the Tag-connect footprint I found is that if you use the footprint (and cables) with the locking holes, you have to use 6mil traces to access the pads.  This is smaller than most of the budget fab houses will accept.  The alternative is to get the cable without the locks, but that makes debugging a PITA, as you have to hold the cable in place the whole time.
  2. Like
    mbeals got a reaction from russcky in Syncing a servo to audio   
    I actually didn't get all that far with the audio.  The memory on the g2553 just wasn't large enough to do what I wanted it to do, and I had to switch focus to other projects before I came up with a solution.  I do plan on coming back to this project, but I will be using an ARM over the MSP.
  3. Like
    mbeals got a reaction from Automate in a simple Command Stack   
    I'm working on a project that is going to involve a device relaying out sensor data while also listening for incoming commands all over UART.  To keep it mostly asynchronous, I decided to write a simple command stack structure.
     
    The idea came from the way you typically receive data over the UART...one character at a time.  The usual formula is to keep reading characters into a buffer until you hit a delimiter, then set a flag to tell the state machine to process the buffer as a command...however this approach blocks the UART, as you have to wait for the state machine to at least copy the command off somewhere before you can allow more data to be written, otherwise the command is corrupted.  Another situation would be a wireless uart, where (power wise) it is better to wake the radio up and send a burst of traffic then put it to sleep, instead of letting the data trickle out.
     
    The stack is composed of a stack of buffers.  One buffer is considered the 'active' buffer, and is the one that is actively written to.  Once a full command is written to the active buffer, it is 'committed', which flags the buffer as ready to be processed and moves on to the next buffer in the stack to start writing again.  In this fashion, you can store a whole list of commands and process them how you see fit, when you see fit.  Each buffer also has an associated 'status' flag, that currently indicates when a buffer is 'ready' to be processed and when a buffer has been overflowed (so the processing code can handle the error), but this can be extended to add other features like command priority.
     
    The basic stack structure looks like this:
    typedef struct { char buffer[STACK_LEN][BUFFER_LEN + 1]; //buffer data store. uint8_t status[STACK_LEN]; // 0x1 = process status; 0x2 = overflow status uint8_t stack_index; //which buffer are we writing to uint8_t buffer_index[STACK_LEN]; //which element of the buffer }command_stack; the meat of the stack is a 2D char array.  The data is organized into  <STACK_LEN> buffers, each <BUFFER_LEN +1> long...the +1 is to allow the buffer to be silently zero terminated.  The idea is that this structure keeps track of itself so the processing code doesn't have to.
     
    'stack_index' indicates which buffer should be written to.
     
    'buffer_index' keeps track of which index in each buffer is the 'end' of the buffer.  Since this acts as a ring buffer, buffers are just overwritten.  Clearing the buffer just involves resetting buffer_index to 0. 
     
    'status' keeps track of the status of each buffer.  Currently there are two implemented options:  the first bit is the 'process status' flag, which indicates if the buffer is ready to be read and processed by other code.  the second is an 'overflow' or 'error' flag.  As data are written to the buffers, if the buffer is overflowed, it just stops writing and sets the overflow flag.  This lets the processing code check and handle the condition gracefully.
     
    To avoid posting a huge® wall of text, I will just cover the basic usage and leave the source up on github:  https://github.com/mjbeals/commandStack
     
    To initialize everything, you just create a command_stack and call buffer_int():
    command_stack test_stack; buffer_init(&test_stack); This creates the stack and initializes it to default values (all zeros).
     
    Writing data into the current active buffer can be char at a time or string at a time:
    write_char(&test_stack, 'C'); write_string(&test_stack, "test"); Once a full command is written, it is time to commit it, which marks it as ready and rolls the stack to the next buffer
    commit_buffer(&test_stack); you can also advance the stack without setting it as 'ready' (in case there was an error, or the buffer should just be discarded) as well as modify the 'ready' status of any buffer
    advance_stack(&test_stack); void flag_buffer(&test_stack, 0, 1); //flag buffer 0 to READY To read back out the buffers, I currently only have two methods written.  The first will just dump out the currently active buffer.  The second will dump out any arbitrary buffer.  Since ideally we just commit a bunch of commands, then let the state machine process those that are ready (FIFO style), there is also a function to find the oldest ready buffer.
    char buffer[BUFFER_LEN+1]; //read the current 'active' buffer uint8_t num_chars = read_current_buffer(&test_stack, buffer); // find the index of the oldest 'ready' buffer and then read it int next_index; uint8_t isValid = oldest_ready(&test_stack, &next_index); uint8_t num_chars; if (isValid) { num_chars = read_buffer(&test_stack, buffer, next_index); } So using this framework, here is a simple uart interrupt handler:
    #pragma vector = USCIAB0RX_VECTOR __interrupt void USCI0RX_ISR(void) { char data = UCA0RXBUF; //Copy from RX buffer, in doing so we ACK the interrupt as well write_char(&rx_stack,data); //if it is a line term char, roll the stack if(data == 0x0D) commit_buffer(&rx_stack); } This will just sit there and fill the stack with commands delimited by 0x0D (it's what XBee radios use for their AT commands, which is the heart of this code).
     
     
    then with a function like:
    int8_t oldest_RX(char* buf) { uint8_t index; // if there is no buffer flagged 'ready', return 0 int8_t ready = oldest_ready(&rx_stack, &index); if (ready == 0) return 0; //read the command off the buffer into 'buf' and mark the buffer processed read_buffer(&rx_stack, buf, (uint8_t) index); flag_buffer(&rx_stack, index, 0); return 1; } the state machine can just 
    int rxstat = 0; char buffer[BUFFER_LEN+1]; while(1) { rxstat = oldest_RX(buffer); //if there is a buffer to process, rxstat = 1, command in buffer //if there is an item on the stack to process if (rxstat) { process_command(buffer); //arbitrary function to process the command } } The github repo also has sample UART code with this integrated.  A basic main loop to loop back received serial data is:
    char buffer[BUFFER_LEN+1]; int rxstat = 0; while(1) { rxstat = oldest_RX(buffer); //if there is an item on the stack to process if (rxstat) { //queue up the incoming command back to the TX stack and send enque_buffer(buffer); process_tx(1); } } It uses some of the new functions I wrote for the uart that I didn't discuss.  They are documented in source, but I may write them up later once I have a chance to refine them.
     
    As it stands, the code works for the test cases I've run, but it is in very alpha stage still.  I'm going to be refining it and adding on to it over the next few weeks especially as I wrap up this project.  One of the first additions is for the 'advance_stack' function to roll to the next (oldest) buffer that does not have a 'ready flag'.
     
    I'm completely open to comments, questions, criticism, etc.  I'm hoping to turn this into my 'go to' library for handling serial on the MSP's as I seem to find myself rewriting things from scratch each time I want to use a UART.
     
     
     
  4. Like
    mbeals got a reaction from spirilis in passing strings around   
    so I scrapped the idea of using strcat.  One of the goals here was to validate data pushed to the stack, actively flagging buffers that overflow, and using strcat was making that problematic.
     
    so thanks for your help.  I seem to have a basic working stack system working with my UART code now.
  5. Like
    mbeals reacted to spirilis in passing strings around   
    Looks right...
    string is a pointer (variable of type "unsigned char *"), therefore a 16-bit unsigned integer referring to the memory address where the string begins, 0x03D3 in this case.  All pointers will be of that type regardless of the flavor -- void *, int *, command_stack *, etc. are all just canonical placeholders for a 16-bit (on MSP430, without the MSP430X 20-bit extensions for devices with >64KB flash) integer containing a simple memory location.
     
    *(string) is the dereferenced contents of the first byte contained within string's memory address, which is 0x54 -- capital letter "T" in the ASCII character set.
  6. Like
    mbeals reacted to chicken in passing strings around   
    Not sure if that's the real issue, but your test code declares string as a single character. Also the parameter buffer, presumably indicating the length of the receiving string-buffer, is ignored in your read function.
     
    Try
     
    char string[BUFFER_LEN];  
    Also the for loop in the read function uses an odd end condition. I'd check I against BUFFER_LEN too. i.e.
     
    for (i = 0; i < BUFFER_LEN; i++)  
    Or, respecting the target buffer length
     
    for (i = 0; i < BUFFER_LEN && i < buffer; i++)
  7. Like
    mbeals got a reaction from bluehash in Wireless model rocket telemetry   
    Some toys came today.
     
    still waiting on the sensor tags though....looks like they won't be shipped until the 2nd week in July


  8. Like
    mbeals got a reaction from roadrunner84 in Wireless model rocket telemetry   
    This is a continuation of a thread I made here: http://forum.43oh.com/topic/3973-mcu-wireless-networking-question/#entry36033
     
    Since we ordered hardware, I figured it was time to start documenting the build.
     
    Background:
    We applied for (and received) a small grant from NASA to build an educational activity for high school kids about the physics of rocketry.   The idea is to allow the kids to design, build and test their own rockets and provide them real time feedback on the performance.  Using this, we will teach them about the concepts of ballistic motion, force, impulse, thrust, etc...
     
    We want a way to measure, log and graph the various forces acting on the rocket during flight without the measuring, logging and graphing getting in the way.  So we decided the best way was to wirelessly transmit a data stream from the payload to a base station which could read, process and graph the data in real-time, maximising the time the students have to conduct experiments.
     
    Design:
    There are two main components to this project, the payload that is contained in the rocket and the base station;
     
    The payloads:
    The current plan for the payloads is going to be a TI sensor tag (thanks @cde) with custom firmware broadcasting a data stream over a Xbee-Pro XSC radio back to the base station.  The payload will be mounted in the nose of the rocket, so room is going to be tight.  I am planning on making an adaptor board to connect the two modules together along with an extended battery pack.
     
    The sensor tag contains:
    IR temperature Sensor On chip temperature Sensor Humidity Sensor Pressure Sensor Accelerometer Gyroscope Magnetometer  This is information overload, but should allow the kids to have tons of room to experiment.  The extended range of the radio will also allow the payloads to be used in other experiments or possibly even in higher altitude rockets.  With a little hacking, the sensor tag should also be able to be modified to break out the i2c bus for adding additional sensors (e.g. GPS).
     
    The Base Station:
    To keep it simple and safe, we decided to forego traditional chemical motors and instead use a compressed air system that will consist of a small compressor attached to a pressure vessel.  Attached to the vessel will be an electric solenoid and a length of PVC pipe.  The rockets will be modified (by removing the engine mounts) to slide down over the PVC pipe, and will be fired by opening the solenoid valve. 
     
    The base station will have dedicated electronics to monitor and control the pump and solenoid, and we are considering a stepper driven belt drive to adjust the launch angle.  Even though it is a low pressure system and there will be interlocks and blow off valves in place, we want to operate it from a safe distance.  Currently we are planning on using a Phidget board controlled by labview to run everything on the base station.  The idea is that the students can adjust the launch angle and pressure, launch their rocket, and see in real time what those changes made to the launch characteristics.  The pressure based launcher also limits the range to several hundred feet, so we don't need to worry about recovery systems or losing rockets when it is windy...and it will be usable in large lecture halls.
     
     
    Communication:
    To communicate with the payloads, we will have a stellaris launchpad with another Xbee-Pro radio mounted on the base station that will act as a hub, aggregating data streams from all transmitting payloads and rebroadcasting them over serial to the main computer, which will handle logging and display.  Because the sensor tag unit in the payload is low power BT enabled, we plan on having a BT dongle on the base station to detect and identify the rocket loaded into the launcher.  This info will be read by the computer logging the data and used to automatically bring up that rocket's data stream.  The BT connection might also be used to wake up the radio out of sleep mode, so that the modules conserve power when not in use. 
     
     
    Right now the project is still in the planning stage.  Parts have been ordered and should be here on Monday except for the sensor tag boards, which are backordered for another 2 weeks.  Once the radios are here, we will start prototyping the network building the base station.  I will update with pictures and updates as the project progresses.
     
     
  9. Like
    mbeals got a reaction from cubeberg in (MCU) Wireless networking question   
    @@jpnorair, We ordered the xbee Pro xsc modules from digi.  It's a 900 MHz radio and they claim 9 miles on a dipole antenna and up to 28 miles with a good directional.  I plan on dropping the transmit power close to the bare minimum to conserve battery and keeping the symbol rate as low as possible.  Considering this will be done in an open field, I think we will have range to spare for this application, but I am looking forward to seeing how far I can push it....a sensor pack like this with good range and mesh topology would be pretty useful for other stuff we do (unrelated to this project)...especially at this low of a price point and ease of assembly.
     
    @@cubeberg, thanks.  Will do.  I keep forgetting how responsive TI's customer support really is.
  10. Like
    mbeals got a reaction from cde in Wireless model rocket telemetry   
    This is a continuation of a thread I made here: http://forum.43oh.com/topic/3973-mcu-wireless-networking-question/#entry36033
     
    Since we ordered hardware, I figured it was time to start documenting the build.
     
    Background:
    We applied for (and received) a small grant from NASA to build an educational activity for high school kids about the physics of rocketry.   The idea is to allow the kids to design, build and test their own rockets and provide them real time feedback on the performance.  Using this, we will teach them about the concepts of ballistic motion, force, impulse, thrust, etc...
     
    We want a way to measure, log and graph the various forces acting on the rocket during flight without the measuring, logging and graphing getting in the way.  So we decided the best way was to wirelessly transmit a data stream from the payload to a base station which could read, process and graph the data in real-time, maximising the time the students have to conduct experiments.
     
    Design:
    There are two main components to this project, the payload that is contained in the rocket and the base station;
     
    The payloads:
    The current plan for the payloads is going to be a TI sensor tag (thanks @cde) with custom firmware broadcasting a data stream over a Xbee-Pro XSC radio back to the base station.  The payload will be mounted in the nose of the rocket, so room is going to be tight.  I am planning on making an adaptor board to connect the two modules together along with an extended battery pack.
     
    The sensor tag contains:
    IR temperature Sensor On chip temperature Sensor Humidity Sensor Pressure Sensor Accelerometer Gyroscope Magnetometer  This is information overload, but should allow the kids to have tons of room to experiment.  The extended range of the radio will also allow the payloads to be used in other experiments or possibly even in higher altitude rockets.  With a little hacking, the sensor tag should also be able to be modified to break out the i2c bus for adding additional sensors (e.g. GPS).
     
    The Base Station:
    To keep it simple and safe, we decided to forego traditional chemical motors and instead use a compressed air system that will consist of a small compressor attached to a pressure vessel.  Attached to the vessel will be an electric solenoid and a length of PVC pipe.  The rockets will be modified (by removing the engine mounts) to slide down over the PVC pipe, and will be fired by opening the solenoid valve. 
     
    The base station will have dedicated electronics to monitor and control the pump and solenoid, and we are considering a stepper driven belt drive to adjust the launch angle.  Even though it is a low pressure system and there will be interlocks and blow off valves in place, we want to operate it from a safe distance.  Currently we are planning on using a Phidget board controlled by labview to run everything on the base station.  The idea is that the students can adjust the launch angle and pressure, launch their rocket, and see in real time what those changes made to the launch characteristics.  The pressure based launcher also limits the range to several hundred feet, so we don't need to worry about recovery systems or losing rockets when it is windy...and it will be usable in large lecture halls.
     
     
    Communication:
    To communicate with the payloads, we will have a stellaris launchpad with another Xbee-Pro radio mounted on the base station that will act as a hub, aggregating data streams from all transmitting payloads and rebroadcasting them over serial to the main computer, which will handle logging and display.  Because the sensor tag unit in the payload is low power BT enabled, we plan on having a BT dongle on the base station to detect and identify the rocket loaded into the launcher.  This info will be read by the computer logging the data and used to automatically bring up that rocket's data stream.  The BT connection might also be used to wake up the radio out of sleep mode, so that the modules conserve power when not in use. 
     
     
    Right now the project is still in the planning stage.  Parts have been ordered and should be here on Monday except for the sensor tag boards, which are backordered for another 2 weeks.  Once the radios are here, we will start prototyping the network building the base station.  I will update with pictures and updates as the project progresses.
     
     
  11. Like
    mbeals got a reaction from spirilis in (MCU) Wireless networking question   
    ordered some parts today.  We decided to take a small risk and picked up 10 of the tag sensor kits as well as an Xbee-pro XSC dev kit and a few extra radios.  Also picked up a handful of launchpads and a few stellaris launch pads to begin working on the networking while we wait for the sensor tags to arrive.
     
    First round of parts will be here on monday, so I think I will move this over to a thread in the projects forum.
     
    Thanks for all of your help everyone
  12. Like
    mbeals reacted to cde in (MCU) Wireless networking question   
    Not personally, but the CC2541 SoC used on the chip is an 8051 compatible chip. (The CC2541 chip comes in a QFN-40 package and not only implements Bluetooth Low Energy, but has a internal  MCS 8051 micro-controller, general purpose timers, accurate RSSI support to allow range determination, two USARTs, 23 general purpose digital IO pins, 12-bit ADC with eight channels, I
  13. Like
    mbeals reacted to jpnorair in (MCU) Wireless networking question   
    Here's a windy response.  Skip to the last two paragraphs if you want the quick answer.  
     
    Assuming equal antennas, the range of a digital wireless comm is dependent on a few things:
    1. the energy of a bit transmitted
    2. the ability of the receiver to efficiently receive a bit
    3. the propagation of the frequency (inversely proportional with frequency)
    4. the level of noise in the environment (proportional with frequency)
     
    If I transmit BLE at 1mW at 1Mbps (or the much-similar Nordic proprietary PHY), the energy-per bit is 1mW X 1us.  So, I can increase the energy per bit by increasing the power of the amp or by increasing the period of the bit (decreasing data rate).
     
    SNR is fundamentally important, also.  One way to get better SNR is to filter the RX better.  Not surprisingly, this can be done by decreasing the data rate, which decreases the bandwidth, all-else-equal.  The term "bandwidth" is not equivalent to data rate, though.  It is just the amount of Hz that 99% of the signal energy can fit into.
     
    The ability of the receiver to decode a bit is dependent on a bunch of calc and trig that I'm not going to explain, but all of that is dependent on the receiver topology itself.  Thing is, there are only three kinds of fundamental modulations: AM, FM, PM.  PM is phase modulation.  It cheap receivers it is much like FM in performance.  In practice, cheap receivers using FM and PM have the best performance.  In more sophisticated receivers, PM can be the best.  In hyper-sophisticated receivers (LTE, WiMax, 802.11n), what you get is a sort-of blend of FSK and PSK.  I've said too much already.
     
    BLE uses GFSK.  G means Gaussian.  FSK means frequency-shift-keying, i.e. binary FM.  So, there is a filter on the transmission to "smooth" the bit, and this helps reduce the bandwidth at the price of making it slightly more difficult for the receiver.  In the end, it is usually a net-zero effect, although I think that most BLE implementations actually filter the TX a bit too much in order to meet spec, rather than use a clean analog chain (range is not a primary feature for BLE).  Filtering too much creates "ISI" or inter-symbol interference.
     
    BLE also has more ISI.  This is because it uses "narrowband" FSK, actually super-narrowband FSK.  "Wideband" FSK includes some signal redundancy in order to make the receiver perform better in the presence of reflections and interference, at the cost of higher bandwidth.  But the plot thickens.  There is a point in the design of receivers where "narrowband" FSK gets so narrow where it is not possible to clearly identify 1 vs 0.  BLE goes quite a bit below this threshold, so some of the transmitter energy is not being used productively.  In fact, more than half of it is wasted in ISI.
     
    WiFi 802.11b is quite pedestrian by modern standards.  It uses a variant of PSK.  g gets more complicated, n starts to get to the point where you need a big DSP to receive *as well as* cutting edge amps because it is sending more than one carrier.  WiFi is very sophisticated.  Bluetooth generally is not, but it is also much cheaper.  That said, an 802.11b implementation is dominated more by its obese IP stack than its PHY/MAC.
  14. Like
    mbeals got a reaction from pine in (MCU) Wireless networking question   
    We just received a small grant from NASA to build an educational activity/demo focused on rocketry.  We are going to build small payloads that contain a basic sensor package (pressure, accelerometer, gyro, temperature, etc) to sit in the nose cone of the rocket and transmit telemetry data back to a base station to display the data in real time.  These are going to be pneumatic (not real rocket engines), so the range will be restricted to hundreds of feet.
     
    Right now we are trying to settle on the best wireless protocol to stream the data.  Communication only needs to be one way, but it needs to be simple and robust.  I would prefer something that supports multiple hosts, so I don't have to worry about activating/deactivating transmitters or returning the receiver.  The favorite so far is zigbee, but I'm not sure which flavor would be the best.  I'm also looking into wizfi modules so we can just use a wireless access point as the receiver and let the modules transmit a UDP data stream.
     
    Can anyone who has experience with this stuff offer a comment?
  15. Like
    mbeals reacted to cde in (MCU) Wireless networking question   
    Nice. Why not the TI bluetooth sensor tag? You could reprogram it so you have all the sensors, and use it with a simple radio VHF module.
  16. Like
    mbeals reacted to spirilis in (MCU) Wireless networking question   
    Fwiw, the Anaren AIR ZigBee boosterpack kit has a full fledged working set of boosterpacks that can run alone and have sensors onboard.  The kit's like $105 though, but it might be a good place to start prototyping.
  17. Like
    mbeals got a reaction from bluehash in Laser Controller   
    After spending some quality time in the code over the weekend, and writing a proper labview front end, I got the laser up and running.  It appears the issue was not having control over the interlock....it wasn't able to enter the warm up cycle and stabilize with the interlock held high.  So once I could pull it low programmatically and wait for the diode temp to stabilize, it kicked right on.
     
    We still have to populate the headers for the LCD, build the case and polish it up, but it seems the big hurdle is over.
     
     
  18. Like
    mbeals got a reaction from spirilis in TTL UART and FTDI - what is what and for what?   
    It even works with non-value line chips that support 2-wire JTAG, which is really handy.  I'm using it right now to debug an F5172 and it is working like a charm.  I started with MSP's and briefly looked into making an arduino clone before seeing how big of a headache programming/debugging was.  Now I've found that TI has port mapping on some chips, PIC's are even starting to lose some favor with me.
  19. Like
    mbeals got a reaction from hawwwran in TTL UART and FTDI - what is what and for what?   
    If the RST line is just attached the RST line of the CP2102, then that's exactly what it is.  If you pull that pin low, the chip powers down.  So you can use it to allow the MCU to disable or reset the chip.  Attaching it to the RST pin on the launchpad means that when you pull the RST line down to reset the MCU on the launchpad, the adaptor is reset as well.
     
    DTR is 'Data Terminal Ready'.  It's a control signal used by RS232 when you are using hardware flow control.  An Arduino is just an AVR MCU with a special serial based bootloader, which is a layer of software that lets you flash a new program over a serial line instead of using a programmer.  They sort of pirate the DTR line to reset the chip and signal when to enter the bootloader and start accepting new code over the serial interface.  To program a MSP430 like this, you would need to first flash bootloader code in the 'usual' way.  However, since the launchpad has a full programmer/debugger built in, there really is no need.
  20. Like
    mbeals got a reaction from bluehash in Laser Controller   
    Haha, nope....didn't get it running yet.  I spent a good part of the day squashing some firmware bugs and validating all of the controller outputs before actually connecting to the laser.  When I finally did hook it up, it was rather anti-climactic....it didn't work.  I'm pretty sure it's just being touchy about the warm-up cycle....all of the inputs are within spec, so I'm going to spend the weekend programming that in and will hopefully get it going on Monday.
     
    We did run into a got-cha with the i2c expander.  With the reset line tied to VCC with a resistor, it doesn't seem to be powering up to a valid state, so that jumper wire is tied to a GPIO line so we can reset it in code before setting up the USCI on the micro.
  21. Like
    mbeals got a reaction from bluehash in Laser Controller   
    Just a quick update.  First prototype is done and programmed with initial firmware.  Serial control works, and the LCD displays stuff, but the encoder and button inputs are still in the works.  We ordered the wrong footprint for a resistor network, which is the missing IC.  The jump wire is just a pull up for prototyping the front panel.  The front panel controls will get their own board, so that jumper will go away.
     
    Unfortunately the solder mask didn't survive the layout updates resulting from switching to the DB25 connector, but the board still looks pretty nice.
     
    I only had time today to power it up and play with the cli, but I'm hooking it up to the laser first thing tomorrow. 

  22. Like
    mbeals got a reaction from spirilis in 43oh Nokia 1202 LCD Display BoosterPack   
    I was just thinking that solder jumper is about the same size as the pads for a 605 component....so if you don't want the filter, soldering the jumper would be virtually the same action as solder bridging the resistor....or are the solder jumpers pre-shorted in copper so that you have to cut the trace to disable it?  I think the spacing is fine...i was thinking more about the redundancy
     
     
    I wonder if it would be worth leaving it as is,  and adding pads for a .1" SMD header around the solder jumper, so that you could install 90* headers pointing to the edge of the board so you can [dis|en]able the filter by adding/pulling the jumper.  I also wonder if it would be worth adding a similar header on the left side of the board with traces that bridge the emitter and collector of the transistor, so you can switch between backlight always on and MCU control by pulling a jumper.
  23. Like
    mbeals got a reaction from spirilis in 43oh Nokia 1202 LCD Display BoosterPack   
    Traditionally wouldn't you connect the mcu pin to the transistor base and the LED cathode to the collector (opposite of what is in the schematic)?  Unless there is a trick I don't know about transistors, I don't see how this is switching the backlight.
     
  24. Like
    mbeals got a reaction from RobG in 43oh Nokia 1202 LCD Display BoosterPack   
    Traditionally wouldn't you connect the mcu pin to the transistor base and the LED cathode to the collector (opposite of what is in the schematic)?  Unless there is a trick I don't know about transistors, I don't see how this is switching the backlight.
     
  25. Like
    mbeals got a reaction from bluehash in Laser Controller   
    So a little update on this project.
     
    Due to the fact I'm trying to finish up my degree this summer and this project is nowhere related to that goal, I passed the torch to someone else who is currently finishing things up.  I should have an unprogrammed prototype in my hands by the end of the week or so and will have a working board with basic firmware by the end of the month.  I'll be sure to post pictures once I get hardware in my hands.
×
×
  • Create New...