Jump to content
43oh

PTB

Members
  • Content Count

    113
  • Joined

  • Last visited

  • Days Won

    5

Reputation Activity

  1. Like
    PTB reacted to Rei Vilo in [Energia Library] Fuel Tank BoosterPack   
    Please find my review of Fuel Tank BoosterPack with a library for Energia and the pins map.
     

     
    Click to enlarge and download.
     

  2. Like
    PTB got a reaction from igor in Stellaris Launchpad - Camera Flash Timer and Measurement Tool   
    Camera Flash Timer and Measurement Tool
     
     
     
    This project is an amalgamation of many other ideas and projects by other brilliant folks plus my own twist on things.
    Hopefully I have given credit to all those whose work I have expanded upon and incorporated.
    Apart from libraries, I have written the majority of the code from scratch implementing what I have learnt from this and other forums.
    Still quite a few bugs and it is probably 80 - 90% complete.
    I did get some perspex laser cut for it, but I didnt have the right software for it and borked the file conversion and received cute little minature versions.
    Will have another shot at that in the near future.
     
    Particular mention goes to the following folks for their posts and/or help.
    Maurice Ribble, Creator of the Camera Axe and Original Multiflash.
    @@RobG , Colour LCD with Touch https://www.tindie.com/products/RobG/color-lcd-boosterpack-touch/ I would be lost without this boosterpack and assistance.
    @@jkabat , http://forum.stellarisiti.com/topic/684-stellaris-fast-analog-reads/ John's Assistance with the Fast Analog reads required was awesome. Thanks!
    @@Rei Vilo, For help on many matters.
    @@calinp, For the porting of PetitFatfs.
    @@bluehash, For the SD card boosterpack. I have pretty much directly copied this circuit into my board.
     
    Thanks guys
     
    Main Components.
     
    RobG's Touchscreen Booster Pack.
    Stellaris Launchpad
    SD Card Socket
    I2C EEPROM
    Flash Sensor
    OptoIsoloators for Flashes
    Indicator LEDs
    Phototransistor
     
    Useage
     
    Takes the original flash signal and triggers up to 8 additonal flashes. The flashes can be either fired instantly or via delayed timings of which there are multiple modes.
     
    - Instant
    - Constant
    - Varies
    - Factor Increasing
    - Factor Decreasing
    - Synchronize
     

     

     

     

     

     
     
    It can also measure T0.1 and T0.5 camera flash durations via another menu.
     

     

     
    For ages I couldn't figure out what the spike was prior to many of the flash measurements. I am thinking it is a prepulse to the main flash which helps ionize the flash prior to main burst.
    If that's what it is, I am pretty stoked I can see it. Just need to modify my calcs routine to ignore it.
     
    http://en.wikipedia.org/wiki/Flashtube
     
    The purpose of measuring the flash lags and durations is an attempt to align flashes with different characteristics so that they are as closely synced as possible which removes ghosting of images.
     
    Jkabats help with fast analog routine has been key to achieving the 1Msps sampling rate.
     
    As each flash is profiled, the full curve data is stored in an I2C EEPROM along with summary details. This is then extracted by the Synchronize routine to set the delays for each flash.
    I have 7 different modes for aligning the flashes timewise. The results don’t differ too much depending on choice of method.
     
    1. Peak (default)
    2. T0.1 Midpoint
    3. T0.1 Centroid of area under curve
    4. T0.5 Midpoint
    5. T0.5 Centroid of area under curve
    6. Full Curve Midpoint
    7. Full Curve Centroid of area under curve
     
    The faster flashes are held back, and they all cross the finish line at the same time.
    The whole flash array inherits the lag of the slowest flash.
     
    All the data from the I2C chip can be written to an SD Card for further analysis on a PC. Here is the data ported to excel.
     

     
    Code
     
    The code is still underway but most things are working.
    This is version 0.26
     
    PTB_Flash_Measurement_Tool.zip
    (The main file is PTB_Iridium.INO . Will need to create folder structure to suit)
     
    Schematic
     
    This is the current schematic but will be updated in the near future to fix some problems.
    Multiflash 3.sch.pdf
     
    Stellaris Launchpad Mods
     
    Remove Resistors R2, R9, R10, R11, R12.
     
    Bugs and Issues
     
    Slowly working through things.
     
    1. Flash Port 3 isn't firing for some reason. I think it used to. I wonder if it is related to issue #2 below.
    2. I ran into strife with my indicator leds. They are Dual Colour red/blue and then I got a better understanding of forward voltage.
    The blue is very close to the operating voltage of 3.3v. I have done arduino thing before this and it was all 5v, so it caught me. (again)
    I am waiting on some lower resistance arrays, but I think this may create other problems to do with how much current the Stellaris can sink.
    http://e2e.ti.com/support/microcontrollers/stellaris_arm/f/471/t/45816.aspx
    Sooooo... I plan to redo the schematic in the near future implementing a darlington array to drive the optos and indicator leds.
    Gotta think that through. It will be my third board revision. Can't keep doing that forever.
    3. I seem to be only able to get it to run with Energia 0009 at the moment. Later versions don't seem to work with touch screen. Deffo my Software issue.
    4. I2C EEPROM Speeds are very slow. There is a lot of data I am writing in there, but I think some better coding on my part will help a lot.
    Luckily that only really affects 2 operations. The rest is zippy enough.
    5. Haven't written code for reading back from SD card into I2C EEPROM Chip.
    6. I seem to have some kind of problem with I2C addressing. I think its an Energia Wire library thing which may have been fixed in later versions.
    I had a 24lc512 but I wanted more space so I dropped in a 24lc1025 which I then found is like 2 different addresses.
    Couldn't write to one bank without writing to the other, so it defeated the purpose. I want more space to save longer curves from more powerful flashes.
    It is currently good enough to deal with common flashes at full power.
    7. I too have the problem of scanning the I2C bus and getting an address found at every address. The I2C Eeprom works as required though.
     
    More as I think of them.....
     
     
    Cheers
     
    PTB
  3. Like
    PTB reacted to igor in How i can understand about...   
    Look in the processor data sheet.
    Since it mentions GPIO - look in the GPIO section,
    check the table of register offsets, find the register at offset 0x100
    see what the 7th6th bit does.
     
    However this one is a little tricky - not listed in table.
    But see section 10.2.1.2 "Data Register Operation" of the LM4F120h5qr data sheet (probably similar section if different processor).
    It uses the low part of the address offset from portC base as a mask to select which data bits to read/write.
    So this should be a way to access bit 6 of port C.
     
    Edit: Addition - To understand the HWREG macro - search through the library source code (or the documentation) to find where
    it is defined, or search for examples.
     
    Edit: Correction - in the first paragraph I used bit numbering starting from 1 (as I tend to think in those terms),
    then in the second paragraph I used numbering starting from 0 (as the data sheet does).
    (So where I said 7th, and where the data sheet said 6th meant the same bit.  Was just using different reference.)
    I have corrected my message, sorry for any confusion.
  4. Like
    PTB reacted to Druzyek in RPN Scientific Calculator   
    Overview
    This is a scientific calculator I built that uses RPN notation. Features:
    BCD number format with 1-255 places Internal accuracy configurable from 6 to 32 decimal places Two separate 200 level stacks Optional scientific notation Functions: (a)sin, (a)cos, (a)tan, y^x, x root y, e^x, ln, 10^x, log, mod 20x4 character LCD 42 buttons The source code is available on https://github.com/druzyek/RPN_Calculator.
     

     
    Software
    The interface shows 4 levels of the stack, similar to some HP calculators. While I was writing the code for BCD calculations, I used a console program to test the routines. You can download it from GitHub if you want to test out the functionality: rpnmain_pc.c It will compile for Windows if #WINDOWS is defined or for Linux with the ncurses library if #LINUX is defined.
    On Windows: gcc -o rpncalc.exe rpnmain_pc.c On Linux: gcc -lncurses -o rpncalc rpnmain_pc.c Numbers are stored in unpacked BCD format on an external SRAM chip. I wanted to access this memory using variables but there is no convenient way to do this since every variable requires a function to access it. A simple functions like:
    X+=Y*Z-Q; would become something like this (assuming we are passing pointers):
    RAM_Write(X,RAM_Read(X)+(RAM_Read(Y)*RAM_Read(Z)-RAM_Read(Q)); To simplify things, I wrote a preprocessor program that looks for any variables that need to be stored in external RAM and converts access to them to function calls. External variables are all stored as pointers, so the PC version will work exactly the same with or without the preprocessor. To mark variables as external, #pragma directives are used. These are usually ignored by the compiler if they are not recognized, so they are a convenient way to communicate with the preprocessor. Here is an example:
    //Before processing void puts(unsigned char *msg) { #pragma MM_VAR msg for (int i=0;msg[i];i++) putchar(msg[i]); } int main() { #pragma MM_OFFSET 200 #pragma MM_DECLARE unsigned char text1[30]; unsigned char text2[30]; #pragma MM_END text1[0]='A'; text1[1]=0; puts(text1); } //After processing void puts(unsigned char *msg) { #pragma MM_VAR msg for (int i=0;RAM_Read(msg+i);i++) putchar(RAM_Read(msg+i)); } int main() { #pragma MM_OFFSET 200 #pragma MM_DECLARE unsigned char *text1=(unsigned char*)200; unsigned char *text2=(unsigned char*)230; #pragma MM_END RAM_Write(text1+0,'A'); RAM_Write(text1+1,0); puts(text1); } The trig and log functions are computed using CORDIC routines. This is a very efficient way to compute these functions for processors that cannot multiply or divide quickly. Instead, a lookup table is used with adds and shifts, which are much faster. I was able to speed the shifting up even more by using another lookup table that let me right shift 4 digits at a time. One way to measure the accuracy of calculations is with the calculator forensic found here: http://www.rskey.org/~mwsebastian/miscprj/forensics.htm. After setting accuracy to 24 places arcsin(arccos(arctan(tan(cos(sin(9)))))) evaluates to this:

     
    The settings page allows the accuracy to be set from 6 to 32 decimal places. With the default of 12, trig functions calculate in about a second. With 32 decimal places calculations take 3-4 seconds. After setting the accuracy, the program finds the largest element in the CORDIC table that is still significant, so that no time is wasted on elements that have no effect on the answer. The settings page also shows the current battery charge.

     
    When I began this project I wasn't sure how much I could fit into 16kB of firmware space. In the end it grew bigger than this and I had to use two MSP430s to hold everything. Part of this is due to all of the functions used to access external memory. The interface code also added a lot more to the size than I expected but I was able to add checks for most of the functions and add some meaningful error messages.

     
    Hardware
    My design uses two MSP430G2553s connected over UART. One of them (the master) reads the keyboard matrix, updates the LCD, and manages the interface. The other is connected to the data lines of 128k of parallel SRAM and does all of the calculating. The address lines of the SRAM are driven by two 74HC595 shift registers controlled by the second MSP430. The 17th address pin is controlled by the first MSP430 and allows the program to switch between two separate stacks. Here is the schematic: 

     
    The keypad is formed from 42 tactile buttons arranged in a 6x7 matrix and read with a 74HC165 shift register by the master MSP430. The LCD and keyboard share the same pins since they are never used at the same time. Here is the layout of the keys.

     
    The LCD is an HD44780 compatible 20x4 character LCD. It is rated for 5v but the logic works fine at 3.6v. The contrast needs to be close to 5v for anything to show up on the screen, so I used a 555 timer and some diodes to supply around -1.2v to the contrast pin. The result is very solid and clear.
     
    The calculator runs on four AA batteries regulated by an LM1117 configured to supply around 3.5 volts. To run at 16MHz the MSP430s need at least 3.3 volts. The wiggle room between the two voltages will let me see when the batteries are starting to wear down. By the time the voltage gets down to 3.3v, the batteries will be down to 1.15v or so, which can be considered dead.
     
    The PCB is made from perfboard. The top of the board contains female headers so that the keyboard and LCD can be unplugged. Part of the board had to be cut away so that it will fit in the case with the batteries. Although it is quite small, I ended up using over three meters of wire.

     
    The case is soldered out of copper clad. I used a lot of solder on it and it feels very sturdy. I will give it a coat of paint tomorrow before assembling everything.

  5. Like
    PTB reacted to chicken in What are you doing right now..?   
    Seems to sell like hotcakes, the UPS man just dropped a Baofeng UV-5R+ on my doorstep I hope to use it as a test signal  to fiddle with my AIS project. (Carrier signal only, I don't think it is able to transmit data)
     
    Besides that, I successfully put my $2.50 reflow oven into production. No more handsoldering of QFNs.

    Heat 0.25" aluminum slab to 160C (gently, it should be stable at 160C or only slowly increasing), add aluminum tray with PCB and temperature probe inside, cover with 2nd tray, wait till PCB reaches 160C plus another minute or so, turn up the stove to max, wait till PCB reaches 220C, take tray off the stove and let cool, season to taste.
     
  6. Like
    PTB got a reaction from RobG in Stellaris Launchpad - Camera Flash Timer and Measurement Tool   
    Camera Flash Timer and Measurement Tool
     
     
     
    This project is an amalgamation of many other ideas and projects by other brilliant folks plus my own twist on things.
    Hopefully I have given credit to all those whose work I have expanded upon and incorporated.
    Apart from libraries, I have written the majority of the code from scratch implementing what I have learnt from this and other forums.
    Still quite a few bugs and it is probably 80 - 90% complete.
    I did get some perspex laser cut for it, but I didnt have the right software for it and borked the file conversion and received cute little minature versions.
    Will have another shot at that in the near future.
     
    Particular mention goes to the following folks for their posts and/or help.
    Maurice Ribble, Creator of the Camera Axe and Original Multiflash.
    @@RobG , Colour LCD with Touch https://www.tindie.com/products/RobG/color-lcd-boosterpack-touch/ I would be lost without this boosterpack and assistance.
    @@jkabat , http://forum.stellarisiti.com/topic/684-stellaris-fast-analog-reads/ John's Assistance with the Fast Analog reads required was awesome. Thanks!
    @@Rei Vilo, For help on many matters.
    @@calinp, For the porting of PetitFatfs.
    @@bluehash, For the SD card boosterpack. I have pretty much directly copied this circuit into my board.
     
    Thanks guys
     
    Main Components.
     
    RobG's Touchscreen Booster Pack.
    Stellaris Launchpad
    SD Card Socket
    I2C EEPROM
    Flash Sensor
    OptoIsoloators for Flashes
    Indicator LEDs
    Phototransistor
     
    Useage
     
    Takes the original flash signal and triggers up to 8 additonal flashes. The flashes can be either fired instantly or via delayed timings of which there are multiple modes.
     
    - Instant
    - Constant
    - Varies
    - Factor Increasing
    - Factor Decreasing
    - Synchronize
     

     

     

     

     

     
     
    It can also measure T0.1 and T0.5 camera flash durations via another menu.
     

     

     
    For ages I couldn't figure out what the spike was prior to many of the flash measurements. I am thinking it is a prepulse to the main flash which helps ionize the flash prior to main burst.
    If that's what it is, I am pretty stoked I can see it. Just need to modify my calcs routine to ignore it.
     
    http://en.wikipedia.org/wiki/Flashtube
     
    The purpose of measuring the flash lags and durations is an attempt to align flashes with different characteristics so that they are as closely synced as possible which removes ghosting of images.
     
    Jkabats help with fast analog routine has been key to achieving the 1Msps sampling rate.
     
    As each flash is profiled, the full curve data is stored in an I2C EEPROM along with summary details. This is then extracted by the Synchronize routine to set the delays for each flash.
    I have 7 different modes for aligning the flashes timewise. The results don’t differ too much depending on choice of method.
     
    1. Peak (default)
    2. T0.1 Midpoint
    3. T0.1 Centroid of area under curve
    4. T0.5 Midpoint
    5. T0.5 Centroid of area under curve
    6. Full Curve Midpoint
    7. Full Curve Centroid of area under curve
     
    The faster flashes are held back, and they all cross the finish line at the same time.
    The whole flash array inherits the lag of the slowest flash.
     
    All the data from the I2C chip can be written to an SD Card for further analysis on a PC. Here is the data ported to excel.
     

     
    Code
     
    The code is still underway but most things are working.
    This is version 0.26
     
    PTB_Flash_Measurement_Tool.zip
    (The main file is PTB_Iridium.INO . Will need to create folder structure to suit)
     
    Schematic
     
    This is the current schematic but will be updated in the near future to fix some problems.
    Multiflash 3.sch.pdf
     
    Stellaris Launchpad Mods
     
    Remove Resistors R2, R9, R10, R11, R12.
     
    Bugs and Issues
     
    Slowly working through things.
     
    1. Flash Port 3 isn't firing for some reason. I think it used to. I wonder if it is related to issue #2 below.
    2. I ran into strife with my indicator leds. They are Dual Colour red/blue and then I got a better understanding of forward voltage.
    The blue is very close to the operating voltage of 3.3v. I have done arduino thing before this and it was all 5v, so it caught me. (again)
    I am waiting on some lower resistance arrays, but I think this may create other problems to do with how much current the Stellaris can sink.
    http://e2e.ti.com/support/microcontrollers/stellaris_arm/f/471/t/45816.aspx
    Sooooo... I plan to redo the schematic in the near future implementing a darlington array to drive the optos and indicator leds.
    Gotta think that through. It will be my third board revision. Can't keep doing that forever.
    3. I seem to be only able to get it to run with Energia 0009 at the moment. Later versions don't seem to work with touch screen. Deffo my Software issue.
    4. I2C EEPROM Speeds are very slow. There is a lot of data I am writing in there, but I think some better coding on my part will help a lot.
    Luckily that only really affects 2 operations. The rest is zippy enough.
    5. Haven't written code for reading back from SD card into I2C EEPROM Chip.
    6. I seem to have some kind of problem with I2C addressing. I think its an Energia Wire library thing which may have been fixed in later versions.
    I had a 24lc512 but I wanted more space so I dropped in a 24lc1025 which I then found is like 2 different addresses.
    Couldn't write to one bank without writing to the other, so it defeated the purpose. I want more space to save longer curves from more powerful flashes.
    It is currently good enough to deal with common flashes at full power.
    7. I too have the problem of scanning the I2C bus and getting an address found at every address. The I2C Eeprom works as required though.
     
    More as I think of them.....
     
     
    Cheers
     
    PTB
  7. Like
    PTB reacted to bluehash in The Booster BoosterPack - LiPo Battery Pack + USB Charger   
    Sent for fab.
     
    @@PTB I missed out on this. Will add the feature in the next rev.
  8. Like
    PTB got a reaction from bluehash in The Booster BoosterPack - LiPo Battery Pack + USB Charger   
    Hi Bluehash,
     
    Just thinking would be nice to have some mounting holes. If this was the lowest board in a stack, it could be screwed down into a case or onto something. Then the whole board sandwich of battery booster pack, launchpad, plus any additional boosters would be mountable via your booster pack.
     
    Just a thought, if you think its not of value or will create problems please ignore.
     
    Cheers
     
    PTB
  9. Like
    PTB reacted to RobG in 10W & 20W RGB LED driver board   
    New driver board, built to fit 20W RGB LEDs. 
     

     

  10. Like
    PTB reacted to grahamf72 in Timed Camera Remote   
    Here's what has been keeping me busy (apart from my real job) since just after Christmas - a timed camera remote.  It is mostly code complete, although could do with a few tweaks here and there. The hardware however isn't quite finished as I'm still waiting for a few parts to be delivered before I can finally finish it - the most critical of which is the 2.5mm stereo plug to go into the camera. Consequently it hasn't actually fired my camera yet, but I'm confident it will work correctly when the final parts arrive.
     
    Background
    Many moons ago, I created a serial port remote release for my Samsung GX10 DSLR, designed to be triggered from my Palm Pilot. I had a program for the palm that would run through a timed sequence, and could trigger the camera remote release through the Palm's serial port. A circuit diagram of the original is here: http://www.flickr.com/photos/gdaj/1317816870/  (my apologies for the link to an image on another site - this was done years ago, and is only slightly relevant to this project).  It worked well but was very limited, and unfortunately after several house moves, the Palm Pilot and the cable seem to have vanished. So when I started playing around with the MSP430, I thought a proper timed shutter release would be a good project. After months of procrastination I finally set to work creating it just after Christmas. 
     
    Functions
    I wanted something that could do more than just fire off a shot every n seconds for x shots. So my aim was for the timer to have multiple modes. The things I wanted it to be able to do were:
    Timed bulb shots (I love night-time photography), capable of handling bracketed shots - so instead of just firing the camera once every n seconds, it should fire it 3 times, or 5 times etc capable of bracketing multiple bulb shots - so the timer has to control longer or shorter exposure times. allow for the camera's inbuilt noise reduction for long exposures - my cameras will do dark-frame subtraction after a long bulb exposure, whereby they take another photograph of the same length of time but with the shutter closed. This means taking multiple bulb shots would have to allow for this time delay I came up with a flow control that allows for all these different scenarios, but still with a fairly straight forward user interface.
     
    The Camera Interface
    I have a Samsung GX10 (Pentax KD10 copy), and a Canon EOS 450D. Both of these cameras use the same interface for the remote release. Physically, the camera has a 2.5mm stereo headphone socket. Electronically, the tip is the shutter, the ring is the focus, and the sleeve is ground. To activate shutter or focus, the tip or ring is connected to ground. An open collector transistor is suitable for this.  The trick is though, that the focus has to be grounded before the shutter. If you look at the above diagram, you'll see they both get their signal from the same pin, and are therefore both grounded at the same time. This mostly works, but if the camera goes into sleep mode, the focus activation will wake it, but it won't acknowledge the shutter press.  My final code allows you to set the delay between when the focus is activated and the shutter is activated, to give the camera time to wake up. This also allows you to use auto-focus if you really want to, by increasing the delay long enough to allow focus.
     
    The Hardware
    The brains behind the operation is an MSP430G2452, currently on the launchpad, but it will ultimately be on a standalone board.  To drive the camera interface, all the MSP430 does is drive a pair of open-collector NPN transistors - I use BC549's but pretty much any small-signal NPN transistor will do the trick.  To convey all the information to the user, a standard 16x2 text LCD module is used, in 4 bit mode. I use a transistor to switch the backlight, controlled from a pin on the 430, and also use a couple of transistors to switch power to the whole module. This allows me to turn the display completely off when not in use, or while doing a long shooting sequence to save power.  Finally, the user interface is controlled by a rotary-coder switch. This uses 3 pins on the 430 - two for the grey-coded rotation and one for the push-button. I initially was using hardware debouncing with capacitors & resistors, and the fact the 430 has Schmidt inputs, but was running into hassles getting reliable operation, so changed to software debouncing.  The 32khz crystal is used to manage the timing.  All up I'm using all but one GPIO pin.  Pin allocation is as follows:
    P1.0 - LCD RS
    P1.1 - LCD EN
    P1.2 - LCD Backlight control
    P1.3 - LCD Power control
    P1.4-P1.7 - LCD D4-D7
    P2.0 - Rotary Coder Pushbutton
    P2.1 & P2.2 - Rotary Coder rotation sensor
    P2.3 - Focus Control
    P2.4 - Shutter Control
    P2.5 - spare. 
    P2.6 & P2.7 - 32kHz crystal
     
    Note - on the attached circuit diagram, you'll see some scribble next to the TEST pin of the MSP430 - this was a mistake and I couldn't find any whiteout. The capacitor and resistor are obviously connected to the RESET pin, not TEST.

     
    Software
    I started out using Energia, but very soon into the design I started running into RAM problems on the 2452, so I put in the 2553. I didn't get much further when I started running into RAM problems with it too. Energia is great in that it is simple to use, and has ready-to-use libraries for a lot of things. But those libraries come with overhead - for example 32 bytes of RAM just to store the list of interrupt functions, even if I'm only using interrupts on 3 pins. So I started again - still in the Energia IDE (because CCS refuses to run on my main development machine), but I didn't use any of the Energia framework. Consequently my code will look familiar to CCS developers. The main file has the .ino extension like all Energia sketches, but if you rename it to .cpp it should compile with GCC no problems. I am using C++, although the only C++ extension I'm using is function type overides. No classes to help keep the code lean.  By restarting in this manner, I was able to go back to the 2452 with 6.6k of code, and no RAM problems.
     
    For readability the code is arranged into separate files for different functions.
    CameraTimerGCC.ino contains main() and has the general flow control.
     
    clocks.cpp sets up the clocks (1MHz main clock, 32.768 crystal for ACLK, WatchDog Timer running at 4Hz) as well as implementing a Wait() routine using TIMER-A & the crystal to pause for a few milliseconds in LPM3.
     
    encoder.cpp implements the rotary encoder. It contains the P2 interrupt which handles the grey-coded rotation sensor and the pushbutton. A variable holds the relative value of the rotation sensor and indicates if the button has been pressed.
     
    flashsave.cpp copies the current settings to flash or reads from flash. I use the 3 user segments of flash (Segments B, C & D) as 3 "slots" to save your settings into.
     
    lcd.cpp is a basic library to drive the LCD. Only the functions that I needed are implemented.
     
    sequence.cpp handles the logic of shooting the programmed sequence
     
    textconstants.cpp - pretty self explanatory holds most (I need to do some tidying up so it is all) of the text constants used for the display.
     
    ui.cpp - implements the main menu
     


     
    UPDATE - 26 January 2014 - Nearing Completion
    Well I finally managed to track down a cable with a 2.5mm plug - after checking all the local "electronics" shops again and drawing a blank, I just happened to be wandering through a department store and saw a lone 2.5mm cable in ratty packaging. Hooked it all up, and nothing. I switched to bulb mode, and still nothing. Then I touched one of the base resistors into one of the transistors, and the camera went nuts.  I soon discovered my error - I hadn't made the connection between the emitters of my driver transistors and ground. With no ground reference the MSP wasn't turning the transistors on, so nothing at the camera. Fixed that, ran a sequence, and the camera woke from sleep but still did nothing. A little tweaking and I discovered my program was sound, the problem was just that the time it was holding the shutter down was too short. Dialled up 100mSec instead of 25mSec and everything leapt into action and was working perfectly.
     
    Then came the trickiest part of the whole exercise - converting my breadboarded circuit into stripboard. After a few hours with a piece of paper printed with a 1/10" grid I finally worked out a layout that would work. It is probably a long way from optimal, and when I look at the board I see a huge amount of wasted space as well as more wire links than I would like, but it works, that's the main thing. I did end up changing a few pin allocations to things that would allow a more efficient board layout.
     
    So last night I sat down and soldered it up. Updated the code with the new pin allocations, flashed it to the 2452, plugged it into the board, connected power, and nothing. Actually not quite true, the backlight flickered a bit. So I poured over the board layout, and found one fault - I had pins P1.6 & P1.7 connected to the LCD's DB7 & DB6 respectively instead of 1.6->DB6, 1.7->DB7. That shouldn't cause the backlight to flicker but it would stop the LCD starting up, so I fixed that and still just had a flickering backlight. All the voltages were what they should be - my 5V line was held at 5.1V by the Zener, my 3.3V line was exactly 3.3V. All the pins on the MSP430 were held at 0, even the rotary coder inputs which should be pulled high. Thinking I may have blown the MSP430 I unplugged it and put it back on the launchpad. With the pin changes, the backlight was now controlled by P1.0, so in theory when I put it back on the launchpad the red led should light for a few seconds before turning off. Nothing. I was pretty sure I'd wrecked the MSP430, so just to test I loaded Energia's basic blinking light program. It was then that I noticed that down the bottom of Energia it said "LaunchPad w/ msp430g2553". Changed that to the msp430g2452, and the blinking light worked. Re-flashed my code and the red led lit up for 10 seconds before turning off. Plugged the 430 back into my board, and everything lit up perfectly just like it should.  Did a test run and it operated perfectly, except I noticed the backlight wasn't going out.
     
    So, now I was trying to find the reason why the backlight stayed on. My first suspicion was a bridged solder track or similar, but couldn't find any.  Next idea was that maybe the controlling transistor had gone short circuit - it had been a little stubborn when I was trying to solder it, the solder didn't want to take. Desoldered it, but I was still getting 0 ohms between the backlight Cathode and ground. Maybe the 10k resistor that I had across the transistor to provide the low backlight was the issue? Removed it, and I was still getting 0 ohms. I came to the conclusion that the problem had to be on the LCD module itself - I was using a brand new module, not the one I had breadboarded. I noticed that the pin for the backlight LED went extremely close to the ground-plane - could it be shorting there? I desoldered the lead (it is sort of wrapped around the end of the board), and the short circuit went away. Soldered the lead back in place and the short circuit was still gone - there must have been a bit of stray solder or something linking it to the ground plane. With that sorted, I put the transistor & resistor back in place, and the backlight control was now working perfectly.
     
    All that remains is to put it in a case, and to change the 2 x 2AA holders for a 4AA holder when it arrives.
     
    Here's a video showing a run-down of the completed unit. 


     
     
    Overall I'm very happy with the result. It is working, and does what I intended for it. Hopefully we'll have some clear nights soon so I can do some long exposure shots.
     
    Another Update
    Now attached is an updated version of the source code. New in this version is:
    Reflects the final pinout that I used when I went to the stripboard.
    Time display is improved. Instead of just displaying the time in seconds, the time is now displayed as a combination of days, hours, minutes & seconds, eg "1 hr 5 min"
    Improved logic within the menus - it skips over the "Burst Interval" option if the Burst Count is 1.
    When bulb mode is off, it states "Bulb Mode Off" Instead of just having a time of 0.
    Improved logic when dialing up large values - For times larger than 3 hours it now goes in 15 minute increments.
    Increased maximum focus time to 10 seconds.
     
    Here's a picture of the (near) finished product on stripboard and showing an example of the new time display.

    CameraTimerUpdated.zip
  11. Like
    PTB reacted to bluehash in Noritake VFD CUY100 24*6 Stellaris Launchpad Interface   
    I used stellarisware for this. There are a couple of example on the Noritake site with menus for an Atmel chip. I ported it over to the Stellaris. Will upload code in a few days.
     



     
     
  12. Like
    PTB reacted to chicken in Stellaris Launchpad - Camera Flash Timer and Measurement Tool   
    Pretty sophisticated piece of equipment. I like the UI.
  13. Like
    PTB reacted to Rei Vilo in Stellaris Launchpad - Camera Flash Timer and Measurement Tool   
    @@PTB
     
    Congratulations for the nice project!
     
    As the look of the screens seems familiar, one question: Are you using the LCD_screen Library Suite or part of it? In that case, any idea on how to improve it? Thank you
  14. Like
    PTB reacted to bluehash in Stellaris Launchpad - Camera Flash Timer and Measurement Tool   
    @@PTB That is some nice work!
  15. Like
    PTB reacted to xpg in Stellaris Launchpad - Camera Flash Timer and Measurement Tool   
    This is an amazing project. Thanks for sharing!
  16. Like
    PTB got a reaction from dubnet in Stellaris Launchpad - Camera Flash Timer and Measurement Tool   
    Camera Flash Timer and Measurement Tool
     
     
     
    This project is an amalgamation of many other ideas and projects by other brilliant folks plus my own twist on things.
    Hopefully I have given credit to all those whose work I have expanded upon and incorporated.
    Apart from libraries, I have written the majority of the code from scratch implementing what I have learnt from this and other forums.
    Still quite a few bugs and it is probably 80 - 90% complete.
    I did get some perspex laser cut for it, but I didnt have the right software for it and borked the file conversion and received cute little minature versions.
    Will have another shot at that in the near future.
     
    Particular mention goes to the following folks for their posts and/or help.
    Maurice Ribble, Creator of the Camera Axe and Original Multiflash.
    @@RobG , Colour LCD with Touch https://www.tindie.com/products/RobG/color-lcd-boosterpack-touch/ I would be lost without this boosterpack and assistance.
    @@jkabat , http://forum.stellarisiti.com/topic/684-stellaris-fast-analog-reads/ John's Assistance with the Fast Analog reads required was awesome. Thanks!
    @@Rei Vilo, For help on many matters.
    @@calinp, For the porting of PetitFatfs.
    @@bluehash, For the SD card boosterpack. I have pretty much directly copied this circuit into my board.
     
    Thanks guys
     
    Main Components.
     
    RobG's Touchscreen Booster Pack.
    Stellaris Launchpad
    SD Card Socket
    I2C EEPROM
    Flash Sensor
    OptoIsoloators for Flashes
    Indicator LEDs
    Phototransistor
     
    Useage
     
    Takes the original flash signal and triggers up to 8 additonal flashes. The flashes can be either fired instantly or via delayed timings of which there are multiple modes.
     
    - Instant
    - Constant
    - Varies
    - Factor Increasing
    - Factor Decreasing
    - Synchronize
     

     

     

     

     

     
     
    It can also measure T0.1 and T0.5 camera flash durations via another menu.
     

     

     
    For ages I couldn't figure out what the spike was prior to many of the flash measurements. I am thinking it is a prepulse to the main flash which helps ionize the flash prior to main burst.
    If that's what it is, I am pretty stoked I can see it. Just need to modify my calcs routine to ignore it.
     
    http://en.wikipedia.org/wiki/Flashtube
     
    The purpose of measuring the flash lags and durations is an attempt to align flashes with different characteristics so that they are as closely synced as possible which removes ghosting of images.
     
    Jkabats help with fast analog routine has been key to achieving the 1Msps sampling rate.
     
    As each flash is profiled, the full curve data is stored in an I2C EEPROM along with summary details. This is then extracted by the Synchronize routine to set the delays for each flash.
    I have 7 different modes for aligning the flashes timewise. The results don’t differ too much depending on choice of method.
     
    1. Peak (default)
    2. T0.1 Midpoint
    3. T0.1 Centroid of area under curve
    4. T0.5 Midpoint
    5. T0.5 Centroid of area under curve
    6. Full Curve Midpoint
    7. Full Curve Centroid of area under curve
     
    The faster flashes are held back, and they all cross the finish line at the same time.
    The whole flash array inherits the lag of the slowest flash.
     
    All the data from the I2C chip can be written to an SD Card for further analysis on a PC. Here is the data ported to excel.
     

     
    Code
     
    The code is still underway but most things are working.
    This is version 0.26
     
    PTB_Flash_Measurement_Tool.zip
    (The main file is PTB_Iridium.INO . Will need to create folder structure to suit)
     
    Schematic
     
    This is the current schematic but will be updated in the near future to fix some problems.
    Multiflash 3.sch.pdf
     
    Stellaris Launchpad Mods
     
    Remove Resistors R2, R9, R10, R11, R12.
     
    Bugs and Issues
     
    Slowly working through things.
     
    1. Flash Port 3 isn't firing for some reason. I think it used to. I wonder if it is related to issue #2 below.
    2. I ran into strife with my indicator leds. They are Dual Colour red/blue and then I got a better understanding of forward voltage.
    The blue is very close to the operating voltage of 3.3v. I have done arduino thing before this and it was all 5v, so it caught me. (again)
    I am waiting on some lower resistance arrays, but I think this may create other problems to do with how much current the Stellaris can sink.
    http://e2e.ti.com/support/microcontrollers/stellaris_arm/f/471/t/45816.aspx
    Sooooo... I plan to redo the schematic in the near future implementing a darlington array to drive the optos and indicator leds.
    Gotta think that through. It will be my third board revision. Can't keep doing that forever.
    3. I seem to be only able to get it to run with Energia 0009 at the moment. Later versions don't seem to work with touch screen. Deffo my Software issue.
    4. I2C EEPROM Speeds are very slow. There is a lot of data I am writing in there, but I think some better coding on my part will help a lot.
    Luckily that only really affects 2 operations. The rest is zippy enough.
    5. Haven't written code for reading back from SD card into I2C EEPROM Chip.
    6. I seem to have some kind of problem with I2C addressing. I think its an Energia Wire library thing which may have been fixed in later versions.
    I had a 24lc512 but I wanted more space so I dropped in a 24lc1025 which I then found is like 2 different addresses.
    Couldn't write to one bank without writing to the other, so it defeated the purpose. I want more space to save longer curves from more powerful flashes.
    It is currently good enough to deal with common flashes at full power.
    7. I too have the problem of scanning the I2C bus and getting an address found at every address. The I2C Eeprom works as required though.
     
    More as I think of them.....
     
     
    Cheers
     
    PTB
  17. Like
    PTB got a reaction from calinp in Stellaris Launchpad - Camera Flash Timer and Measurement Tool   
    Camera Flash Timer and Measurement Tool
     
     
     
    This project is an amalgamation of many other ideas and projects by other brilliant folks plus my own twist on things.
    Hopefully I have given credit to all those whose work I have expanded upon and incorporated.
    Apart from libraries, I have written the majority of the code from scratch implementing what I have learnt from this and other forums.
    Still quite a few bugs and it is probably 80 - 90% complete.
    I did get some perspex laser cut for it, but I didnt have the right software for it and borked the file conversion and received cute little minature versions.
    Will have another shot at that in the near future.
     
    Particular mention goes to the following folks for their posts and/or help.
    Maurice Ribble, Creator of the Camera Axe and Original Multiflash.
    @@RobG , Colour LCD with Touch https://www.tindie.com/products/RobG/color-lcd-boosterpack-touch/ I would be lost without this boosterpack and assistance.
    @@jkabat , http://forum.stellarisiti.com/topic/684-stellaris-fast-analog-reads/ John's Assistance with the Fast Analog reads required was awesome. Thanks!
    @@Rei Vilo, For help on many matters.
    @@calinp, For the porting of PetitFatfs.
    @@bluehash, For the SD card boosterpack. I have pretty much directly copied this circuit into my board.
     
    Thanks guys
     
    Main Components.
     
    RobG's Touchscreen Booster Pack.
    Stellaris Launchpad
    SD Card Socket
    I2C EEPROM
    Flash Sensor
    OptoIsoloators for Flashes
    Indicator LEDs
    Phototransistor
     
    Useage
     
    Takes the original flash signal and triggers up to 8 additonal flashes. The flashes can be either fired instantly or via delayed timings of which there are multiple modes.
     
    - Instant
    - Constant
    - Varies
    - Factor Increasing
    - Factor Decreasing
    - Synchronize
     

     

     

     

     

     
     
    It can also measure T0.1 and T0.5 camera flash durations via another menu.
     

     

     
    For ages I couldn't figure out what the spike was prior to many of the flash measurements. I am thinking it is a prepulse to the main flash which helps ionize the flash prior to main burst.
    If that's what it is, I am pretty stoked I can see it. Just need to modify my calcs routine to ignore it.
     
    http://en.wikipedia.org/wiki/Flashtube
     
    The purpose of measuring the flash lags and durations is an attempt to align flashes with different characteristics so that they are as closely synced as possible which removes ghosting of images.
     
    Jkabats help with fast analog routine has been key to achieving the 1Msps sampling rate.
     
    As each flash is profiled, the full curve data is stored in an I2C EEPROM along with summary details. This is then extracted by the Synchronize routine to set the delays for each flash.
    I have 7 different modes for aligning the flashes timewise. The results don’t differ too much depending on choice of method.
     
    1. Peak (default)
    2. T0.1 Midpoint
    3. T0.1 Centroid of area under curve
    4. T0.5 Midpoint
    5. T0.5 Centroid of area under curve
    6. Full Curve Midpoint
    7. Full Curve Centroid of area under curve
     
    The faster flashes are held back, and they all cross the finish line at the same time.
    The whole flash array inherits the lag of the slowest flash.
     
    All the data from the I2C chip can be written to an SD Card for further analysis on a PC. Here is the data ported to excel.
     

     
    Code
     
    The code is still underway but most things are working.
    This is version 0.26
     
    PTB_Flash_Measurement_Tool.zip
    (The main file is PTB_Iridium.INO . Will need to create folder structure to suit)
     
    Schematic
     
    This is the current schematic but will be updated in the near future to fix some problems.
    Multiflash 3.sch.pdf
     
    Stellaris Launchpad Mods
     
    Remove Resistors R2, R9, R10, R11, R12.
     
    Bugs and Issues
     
    Slowly working through things.
     
    1. Flash Port 3 isn't firing for some reason. I think it used to. I wonder if it is related to issue #2 below.
    2. I ran into strife with my indicator leds. They are Dual Colour red/blue and then I got a better understanding of forward voltage.
    The blue is very close to the operating voltage of 3.3v. I have done arduino thing before this and it was all 5v, so it caught me. (again)
    I am waiting on some lower resistance arrays, but I think this may create other problems to do with how much current the Stellaris can sink.
    http://e2e.ti.com/support/microcontrollers/stellaris_arm/f/471/t/45816.aspx
    Sooooo... I plan to redo the schematic in the near future implementing a darlington array to drive the optos and indicator leds.
    Gotta think that through. It will be my third board revision. Can't keep doing that forever.
    3. I seem to be only able to get it to run with Energia 0009 at the moment. Later versions don't seem to work with touch screen. Deffo my Software issue.
    4. I2C EEPROM Speeds are very slow. There is a lot of data I am writing in there, but I think some better coding on my part will help a lot.
    Luckily that only really affects 2 operations. The rest is zippy enough.
    5. Haven't written code for reading back from SD card into I2C EEPROM Chip.
    6. I seem to have some kind of problem with I2C addressing. I think its an Energia Wire library thing which may have been fixed in later versions.
    I had a 24lc512 but I wanted more space so I dropped in a 24lc1025 which I then found is like 2 different addresses.
    Couldn't write to one bank without writing to the other, so it defeated the purpose. I want more space to save longer curves from more powerful flashes.
    It is currently good enough to deal with common flashes at full power.
    7. I too have the problem of scanning the I2C bus and getting an address found at every address. The I2C Eeprom works as required though.
     
    More as I think of them.....
     
     
    Cheers
     
    PTB
  18. Like
    PTB got a reaction from chicken in Stellaris Launchpad - Camera Flash Timer and Measurement Tool   
    Camera Flash Timer and Measurement Tool
     
     
     
    This project is an amalgamation of many other ideas and projects by other brilliant folks plus my own twist on things.
    Hopefully I have given credit to all those whose work I have expanded upon and incorporated.
    Apart from libraries, I have written the majority of the code from scratch implementing what I have learnt from this and other forums.
    Still quite a few bugs and it is probably 80 - 90% complete.
    I did get some perspex laser cut for it, but I didnt have the right software for it and borked the file conversion and received cute little minature versions.
    Will have another shot at that in the near future.
     
    Particular mention goes to the following folks for their posts and/or help.
    Maurice Ribble, Creator of the Camera Axe and Original Multiflash.
    @@RobG , Colour LCD with Touch https://www.tindie.com/products/RobG/color-lcd-boosterpack-touch/ I would be lost without this boosterpack and assistance.
    @@jkabat , http://forum.stellarisiti.com/topic/684-stellaris-fast-analog-reads/ John's Assistance with the Fast Analog reads required was awesome. Thanks!
    @@Rei Vilo, For help on many matters.
    @@calinp, For the porting of PetitFatfs.
    @@bluehash, For the SD card boosterpack. I have pretty much directly copied this circuit into my board.
     
    Thanks guys
     
    Main Components.
     
    RobG's Touchscreen Booster Pack.
    Stellaris Launchpad
    SD Card Socket
    I2C EEPROM
    Flash Sensor
    OptoIsoloators for Flashes
    Indicator LEDs
    Phototransistor
     
    Useage
     
    Takes the original flash signal and triggers up to 8 additonal flashes. The flashes can be either fired instantly or via delayed timings of which there are multiple modes.
     
    - Instant
    - Constant
    - Varies
    - Factor Increasing
    - Factor Decreasing
    - Synchronize
     

     

     

     

     

     
     
    It can also measure T0.1 and T0.5 camera flash durations via another menu.
     

     

     
    For ages I couldn't figure out what the spike was prior to many of the flash measurements. I am thinking it is a prepulse to the main flash which helps ionize the flash prior to main burst.
    If that's what it is, I am pretty stoked I can see it. Just need to modify my calcs routine to ignore it.
     
    http://en.wikipedia.org/wiki/Flashtube
     
    The purpose of measuring the flash lags and durations is an attempt to align flashes with different characteristics so that they are as closely synced as possible which removes ghosting of images.
     
    Jkabats help with fast analog routine has been key to achieving the 1Msps sampling rate.
     
    As each flash is profiled, the full curve data is stored in an I2C EEPROM along with summary details. This is then extracted by the Synchronize routine to set the delays for each flash.
    I have 7 different modes for aligning the flashes timewise. The results don’t differ too much depending on choice of method.
     
    1. Peak (default)
    2. T0.1 Midpoint
    3. T0.1 Centroid of area under curve
    4. T0.5 Midpoint
    5. T0.5 Centroid of area under curve
    6. Full Curve Midpoint
    7. Full Curve Centroid of area under curve
     
    The faster flashes are held back, and they all cross the finish line at the same time.
    The whole flash array inherits the lag of the slowest flash.
     
    All the data from the I2C chip can be written to an SD Card for further analysis on a PC. Here is the data ported to excel.
     

     
    Code
     
    The code is still underway but most things are working.
    This is version 0.26
     
    PTB_Flash_Measurement_Tool.zip
    (The main file is PTB_Iridium.INO . Will need to create folder structure to suit)
     
    Schematic
     
    This is the current schematic but will be updated in the near future to fix some problems.
    Multiflash 3.sch.pdf
     
    Stellaris Launchpad Mods
     
    Remove Resistors R2, R9, R10, R11, R12.
     
    Bugs and Issues
     
    Slowly working through things.
     
    1. Flash Port 3 isn't firing for some reason. I think it used to. I wonder if it is related to issue #2 below.
    2. I ran into strife with my indicator leds. They are Dual Colour red/blue and then I got a better understanding of forward voltage.
    The blue is very close to the operating voltage of 3.3v. I have done arduino thing before this and it was all 5v, so it caught me. (again)
    I am waiting on some lower resistance arrays, but I think this may create other problems to do with how much current the Stellaris can sink.
    http://e2e.ti.com/support/microcontrollers/stellaris_arm/f/471/t/45816.aspx
    Sooooo... I plan to redo the schematic in the near future implementing a darlington array to drive the optos and indicator leds.
    Gotta think that through. It will be my third board revision. Can't keep doing that forever.
    3. I seem to be only able to get it to run with Energia 0009 at the moment. Later versions don't seem to work with touch screen. Deffo my Software issue.
    4. I2C EEPROM Speeds are very slow. There is a lot of data I am writing in there, but I think some better coding on my part will help a lot.
    Luckily that only really affects 2 operations. The rest is zippy enough.
    5. Haven't written code for reading back from SD card into I2C EEPROM Chip.
    6. I seem to have some kind of problem with I2C addressing. I think its an Energia Wire library thing which may have been fixed in later versions.
    I had a 24lc512 but I wanted more space so I dropped in a 24lc1025 which I then found is like 2 different addresses.
    Couldn't write to one bank without writing to the other, so it defeated the purpose. I want more space to save longer curves from more powerful flashes.
    It is currently good enough to deal with common flashes at full power.
    7. I too have the problem of scanning the I2C bus and getting an address found at every address. The I2C Eeprom works as required though.
     
    More as I think of them.....
     
     
    Cheers
     
    PTB
  19. Like
    PTB got a reaction from bluehash in Stellaris Launchpad - Camera Flash Timer and Measurement Tool   
    Camera Flash Timer and Measurement Tool
     
     
     
    This project is an amalgamation of many other ideas and projects by other brilliant folks plus my own twist on things.
    Hopefully I have given credit to all those whose work I have expanded upon and incorporated.
    Apart from libraries, I have written the majority of the code from scratch implementing what I have learnt from this and other forums.
    Still quite a few bugs and it is probably 80 - 90% complete.
    I did get some perspex laser cut for it, but I didnt have the right software for it and borked the file conversion and received cute little minature versions.
    Will have another shot at that in the near future.
     
    Particular mention goes to the following folks for their posts and/or help.
    Maurice Ribble, Creator of the Camera Axe and Original Multiflash.
    @@RobG , Colour LCD with Touch https://www.tindie.com/products/RobG/color-lcd-boosterpack-touch/ I would be lost without this boosterpack and assistance.
    @@jkabat , http://forum.stellarisiti.com/topic/684-stellaris-fast-analog-reads/ John's Assistance with the Fast Analog reads required was awesome. Thanks!
    @@Rei Vilo, For help on many matters.
    @@calinp, For the porting of PetitFatfs.
    @@bluehash, For the SD card boosterpack. I have pretty much directly copied this circuit into my board.
     
    Thanks guys
     
    Main Components.
     
    RobG's Touchscreen Booster Pack.
    Stellaris Launchpad
    SD Card Socket
    I2C EEPROM
    Flash Sensor
    OptoIsoloators for Flashes
    Indicator LEDs
    Phototransistor
     
    Useage
     
    Takes the original flash signal and triggers up to 8 additonal flashes. The flashes can be either fired instantly or via delayed timings of which there are multiple modes.
     
    - Instant
    - Constant
    - Varies
    - Factor Increasing
    - Factor Decreasing
    - Synchronize
     

     

     

     

     

     
     
    It can also measure T0.1 and T0.5 camera flash durations via another menu.
     

     

     
    For ages I couldn't figure out what the spike was prior to many of the flash measurements. I am thinking it is a prepulse to the main flash which helps ionize the flash prior to main burst.
    If that's what it is, I am pretty stoked I can see it. Just need to modify my calcs routine to ignore it.
     
    http://en.wikipedia.org/wiki/Flashtube
     
    The purpose of measuring the flash lags and durations is an attempt to align flashes with different characteristics so that they are as closely synced as possible which removes ghosting of images.
     
    Jkabats help with fast analog routine has been key to achieving the 1Msps sampling rate.
     
    As each flash is profiled, the full curve data is stored in an I2C EEPROM along with summary details. This is then extracted by the Synchronize routine to set the delays for each flash.
    I have 7 different modes for aligning the flashes timewise. The results don’t differ too much depending on choice of method.
     
    1. Peak (default)
    2. T0.1 Midpoint
    3. T0.1 Centroid of area under curve
    4. T0.5 Midpoint
    5. T0.5 Centroid of area under curve
    6. Full Curve Midpoint
    7. Full Curve Centroid of area under curve
     
    The faster flashes are held back, and they all cross the finish line at the same time.
    The whole flash array inherits the lag of the slowest flash.
     
    All the data from the I2C chip can be written to an SD Card for further analysis on a PC. Here is the data ported to excel.
     

     
    Code
     
    The code is still underway but most things are working.
    This is version 0.26
     
    PTB_Flash_Measurement_Tool.zip
    (The main file is PTB_Iridium.INO . Will need to create folder structure to suit)
     
    Schematic
     
    This is the current schematic but will be updated in the near future to fix some problems.
    Multiflash 3.sch.pdf
     
    Stellaris Launchpad Mods
     
    Remove Resistors R2, R9, R10, R11, R12.
     
    Bugs and Issues
     
    Slowly working through things.
     
    1. Flash Port 3 isn't firing for some reason. I think it used to. I wonder if it is related to issue #2 below.
    2. I ran into strife with my indicator leds. They are Dual Colour red/blue and then I got a better understanding of forward voltage.
    The blue is very close to the operating voltage of 3.3v. I have done arduino thing before this and it was all 5v, so it caught me. (again)
    I am waiting on some lower resistance arrays, but I think this may create other problems to do with how much current the Stellaris can sink.
    http://e2e.ti.com/support/microcontrollers/stellaris_arm/f/471/t/45816.aspx
    Sooooo... I plan to redo the schematic in the near future implementing a darlington array to drive the optos and indicator leds.
    Gotta think that through. It will be my third board revision. Can't keep doing that forever.
    3. I seem to be only able to get it to run with Energia 0009 at the moment. Later versions don't seem to work with touch screen. Deffo my Software issue.
    4. I2C EEPROM Speeds are very slow. There is a lot of data I am writing in there, but I think some better coding on my part will help a lot.
    Luckily that only really affects 2 operations. The rest is zippy enough.
    5. Haven't written code for reading back from SD card into I2C EEPROM Chip.
    6. I seem to have some kind of problem with I2C addressing. I think its an Energia Wire library thing which may have been fixed in later versions.
    I had a 24lc512 but I wanted more space so I dropped in a 24lc1025 which I then found is like 2 different addresses.
    Couldn't write to one bank without writing to the other, so it defeated the purpose. I want more space to save longer curves from more powerful flashes.
    It is currently good enough to deal with common flashes at full power.
    7. I too have the problem of scanning the I2C bus and getting an address found at every address. The I2C Eeprom works as required though.
     
    More as I think of them.....
     
     
    Cheers
     
    PTB
  20. Like
    PTB got a reaction from xpg in Stellaris Launchpad - Camera Flash Timer and Measurement Tool   
    Camera Flash Timer and Measurement Tool
     
     
     
    This project is an amalgamation of many other ideas and projects by other brilliant folks plus my own twist on things.
    Hopefully I have given credit to all those whose work I have expanded upon and incorporated.
    Apart from libraries, I have written the majority of the code from scratch implementing what I have learnt from this and other forums.
    Still quite a few bugs and it is probably 80 - 90% complete.
    I did get some perspex laser cut for it, but I didnt have the right software for it and borked the file conversion and received cute little minature versions.
    Will have another shot at that in the near future.
     
    Particular mention goes to the following folks for their posts and/or help.
    Maurice Ribble, Creator of the Camera Axe and Original Multiflash.
    @@RobG , Colour LCD with Touch https://www.tindie.com/products/RobG/color-lcd-boosterpack-touch/ I would be lost without this boosterpack and assistance.
    @@jkabat , http://forum.stellarisiti.com/topic/684-stellaris-fast-analog-reads/ John's Assistance with the Fast Analog reads required was awesome. Thanks!
    @@Rei Vilo, For help on many matters.
    @@calinp, For the porting of PetitFatfs.
    @@bluehash, For the SD card boosterpack. I have pretty much directly copied this circuit into my board.
     
    Thanks guys
     
    Main Components.
     
    RobG's Touchscreen Booster Pack.
    Stellaris Launchpad
    SD Card Socket
    I2C EEPROM
    Flash Sensor
    OptoIsoloators for Flashes
    Indicator LEDs
    Phototransistor
     
    Useage
     
    Takes the original flash signal and triggers up to 8 additonal flashes. The flashes can be either fired instantly or via delayed timings of which there are multiple modes.
     
    - Instant
    - Constant
    - Varies
    - Factor Increasing
    - Factor Decreasing
    - Synchronize
     

     

     

     

     

     
     
    It can also measure T0.1 and T0.5 camera flash durations via another menu.
     

     

     
    For ages I couldn't figure out what the spike was prior to many of the flash measurements. I am thinking it is a prepulse to the main flash which helps ionize the flash prior to main burst.
    If that's what it is, I am pretty stoked I can see it. Just need to modify my calcs routine to ignore it.
     
    http://en.wikipedia.org/wiki/Flashtube
     
    The purpose of measuring the flash lags and durations is an attempt to align flashes with different characteristics so that they are as closely synced as possible which removes ghosting of images.
     
    Jkabats help with fast analog routine has been key to achieving the 1Msps sampling rate.
     
    As each flash is profiled, the full curve data is stored in an I2C EEPROM along with summary details. This is then extracted by the Synchronize routine to set the delays for each flash.
    I have 7 different modes for aligning the flashes timewise. The results don’t differ too much depending on choice of method.
     
    1. Peak (default)
    2. T0.1 Midpoint
    3. T0.1 Centroid of area under curve
    4. T0.5 Midpoint
    5. T0.5 Centroid of area under curve
    6. Full Curve Midpoint
    7. Full Curve Centroid of area under curve
     
    The faster flashes are held back, and they all cross the finish line at the same time.
    The whole flash array inherits the lag of the slowest flash.
     
    All the data from the I2C chip can be written to an SD Card for further analysis on a PC. Here is the data ported to excel.
     

     
    Code
     
    The code is still underway but most things are working.
    This is version 0.26
     
    PTB_Flash_Measurement_Tool.zip
    (The main file is PTB_Iridium.INO . Will need to create folder structure to suit)
     
    Schematic
     
    This is the current schematic but will be updated in the near future to fix some problems.
    Multiflash 3.sch.pdf
     
    Stellaris Launchpad Mods
     
    Remove Resistors R2, R9, R10, R11, R12.
     
    Bugs and Issues
     
    Slowly working through things.
     
    1. Flash Port 3 isn't firing for some reason. I think it used to. I wonder if it is related to issue #2 below.
    2. I ran into strife with my indicator leds. They are Dual Colour red/blue and then I got a better understanding of forward voltage.
    The blue is very close to the operating voltage of 3.3v. I have done arduino thing before this and it was all 5v, so it caught me. (again)
    I am waiting on some lower resistance arrays, but I think this may create other problems to do with how much current the Stellaris can sink.
    http://e2e.ti.com/support/microcontrollers/stellaris_arm/f/471/t/45816.aspx
    Sooooo... I plan to redo the schematic in the near future implementing a darlington array to drive the optos and indicator leds.
    Gotta think that through. It will be my third board revision. Can't keep doing that forever.
    3. I seem to be only able to get it to run with Energia 0009 at the moment. Later versions don't seem to work with touch screen. Deffo my Software issue.
    4. I2C EEPROM Speeds are very slow. There is a lot of data I am writing in there, but I think some better coding on my part will help a lot.
    Luckily that only really affects 2 operations. The rest is zippy enough.
    5. Haven't written code for reading back from SD card into I2C EEPROM Chip.
    6. I seem to have some kind of problem with I2C addressing. I think its an Energia Wire library thing which may have been fixed in later versions.
    I had a 24lc512 but I wanted more space so I dropped in a 24lc1025 which I then found is like 2 different addresses.
    Couldn't write to one bank without writing to the other, so it defeated the purpose. I want more space to save longer curves from more powerful flashes.
    It is currently good enough to deal with common flashes at full power.
    7. I too have the problem of scanning the I2C bus and getting an address found at every address. The I2C Eeprom works as required though.
     
    More as I think of them.....
     
     
    Cheers
     
    PTB
  21. Like
    PTB reacted to bluehash in Members will now be warned for incorrect post content format.   
    @@PTB You need to select more reply options and select attach files at the bottom of the post.
  22. Like
    PTB reacted to greeeg in 120 LED Ring Clock   
    Hey, It's been along time since I've posted. but I've been keeping busy with uni and working on some cool projects for the last year.
     
    This is something I'd like to share with you guys, it's not finished yet but the hardware is more or less complete. It is an RGB LED ring clock.
     

     
    The clock is comprised of 2 rings of 60 LEDs each. the LEDs are WS2812 parts, which include a built-in driver.
     
    The PCB is one of the interesting parts of this clock. I designed the board in altium as a single 6 LED segment. and then left pads at each end to allow them to be soldered onto another segment.
     

     
    Using seeed's 10pcs PCB program I was able to create the full ring.
     
    Currently I am using a MSP-EXP430FR5739 board to drive it, using some very in-efficient assembly code that requires a 20MHz clock.
     
    I'd like to optimise the code to use an internal SPI module? or timer to bring that clock speed down.
    Hopefully also design a control segment with LEDs on one side that could replace one of the current segments in the ring.
     

     
     
    Edit: I've built up a simple controller based on the G2121. yes, 1kb Flash, 128b of RAM!
     
    I decided to test my asmebly skills and use naken430 the msp430 assembler. Here is my code
    G2121_ledRing.zip
     
    I also added a ring of perspex to help difuse the LEDs
     
    Here is a video of the clock in action.
    http://www.youtube.com/watch?v=tBCvR4BA7pw
     
     
    edit: 06/03/14
    Version 2_02!
    Major differences:
    "double" so you need only 5 pcs to make a full ring, the pieces fit in 5x10cm Uses new 4 pin WS2812b parts
     
    PCBs arrived, been tested and is functional, but has some very small issues.
    Known Errata:
    Doesn't account for very small milling tolerance, means small gaps at joins No silkscreen for LED footprint, only shows orientation Edge connectors a few mm from the edge. Vias connecting to pour have star connections, should be direct connection Thin soldermask trace around OSHW logo is to thin 1 LED under OSHW logo isn't concentric with the rest of the LEDs (<1mm off)  
     
    There is also a special controller board in the mail, this will be tested and documented when it arrives.
     
    edit 2/06/13
    Please see this project for lot of photos and additional information about version 2_02
     
    Version 3!

    Boards have been designed, and I have some prototypes on the way. Designed mainly to upgrade the MSP430 used in the last design to a more capable one.  Boards arrived Some small errata found, pads to small for regulator, JTAG pins in wrong order. New board has been design to fix these issues. There is a tindie page where you can register any interest in buying.
    https://www.tindie.com/products/Greeeg/ledring-clock/
  23. Like
    PTB reacted to Rei Vilo in [Energia Library] Fuel Tank BoosterPack   
    Please find a library for the Fuel Tank BoosterPack with an example and the accompanying reference manual.
     
    Distribution-101.zip
    FuelTank - Reference Manual.pdf
     
    The library has been tested on a Stellaris LaunchPad, with the shunts R9 and R10 in place so the I
  24. Like
    PTB got a reaction from abecedarian in Giveaway Winners: Hercules LAUNCHXL-TMS57004   
    I get the feeling that is going to go to good use.
     
    Congrats Abecedarian.
  25. Like
    PTB reacted to bluehash in configuration data store in flash or SD card   
    @@JWoodrell
    I can suggest two options.
     
    1. Stuff the entire config into a structure and write that structure to a file. When you read the file, read it back to the structure.
    2. Use minINI an open source parser. Has hooks for elm-chan fatFS.
×
×
  • Create New...