Jump to content

yosh

Members
  • Content Count

    207
  • Joined

  • Last visited

  • Days Won

    14

Reputation Activity

  1. Like
    yosh reacted to NurseBob in New Test Rig...   
    I like the boosterPack concept, but for my current project I needed access to all the pins on an F5529 as well as an F2013.  So, I constructed a couple of boards to plug into an MSP-TS430PN80USB in a boosterpack fashion. As is  probably obvious, I missed a couple of traces (GND lines), for which I had to add the little green wires. The top board has all my sensors, and the bottom is basically battery management and a sx1509 port expander to manage a number of LEDs.  I don't actually need the extra ports, but I wanted the sx1509's built-in LED "breathe" capability. Saves coding... -lazy programmer
    I was a happy camper when I fired-up the system and was able to access and program both MCUs.
    I've found that I can choose between running two instances of IAR (or CCS) and debug both micros simulaneously.  Handy for the comms and interrupt handing.
    So, let the fun begin...
     
    BTW - the TFT LCD is from buydisplay.com - 2.8" TFT with Cap touch (about $15.00 U.S.).  It's using the ILI9341 controller for the LCD and the FT6206 controller for the cap touch.  For proof of concept I was able to use the Adafruit sketches to connect with both, and the edits were limited to pin assignments, if I remember correctly.



  2. Like
    yosh reacted to chicken in [POTM] dAISy - A Simple AIS Receiver   
    Tindie business slowed down considerably over the last two months. Not sure yet if it's the cheap competition that started showing up, or whether everyone's just out sailing.
     
    Anyways, the upside is, that I finally have some time to tinker on new things again..

     
    Love the new steel stencils from OSH Stencils. I managed to reflow 4 boards without a single bridge, including the big QFN which gave me a lot of grief in the past. Maybe it's the combination with OSH Park PCBs instead of the cheap Chinese ones. Also OSH Park turned around my last few orders in two weeks from ordering to receiving the boards in my mailbox. I seem to remember that this was closer to three weeks in the past. 
  3. Like
    yosh reacted to will in Temperature & Humidity sensor -with LCD & RF   
    Hi everyone, this is my credit card size wireless sensor node,
    with a 7-seg LCD display showing temperature & humidity, update every second.
    using MSP430FR4133 with HDC1080,BMP180 and OPT3002, 
    transmit by nRF24l01, which sends out temp,humid,pressure,luminosity and also battery voltage per minute.
     

     
    It is all power by a CR2032, and thanks to MSP430FR4133, I can manage to have half an year battery life.

    also thanks to MSP430RF4133 Launchpad with build-in energyTrace, I can estimate battery life with a click(no more oscilloscope  )

    note that I've actually put an RF430 on the down left ot the board(there is an antenna for that),
    which will act as a NFC tag, but it draws too much current (~15uA), so I took it off
    and at the down right is the battery voltage measurement with a mosfet to cut the power,
    but I found out that I can just measure internal voltage reference to calculate its supply voltage, so I've also remove that. 

     
    although I'm pretty much satisfy with this power consumption, but I still think that 16.5uA is a little bit too far from estimating from datasheet
    and I am still trying to figure that out
  4. Like
    yosh got a reaction from reaper7 in Custom MSP430-Board for EasyDriver   
    Hi @@qgs ...
     
    attached you will find the Diptrace file for the PCB. The layout (regarding the MCU) is for G2452/G2553.
     
    EasyDriverMSP430.zip
     
    The simple Energia sketch (not cleaned up, hopefully self explaining, but working) I used to start/stop/reverse my stepper motor is here:
    const int buttonPin = P1_0; //Button for start/stop/reverseconst int DIR_PIN = P2_2;const int STEP_PIN = P2_1;//Motor stateint motorState = 1; // 0/2 = STOP, 1 = CW, 3 = CCW//Buttonint buttonState;int lastButtonState = LOW;long lastDebounceTime = 0;const int debounceDelay = 500;void setup() { //Set EasyDriver Pins for DIR and STEP pinMode(DIR_PIN, OUTPUT); pinMode(STEP_PIN, OUTPUT); digitalWrite(DIR_PIN, HIGH); digitalWrite(STEP_PIN, LOW); //Set Full-Step Mode -> MS1/MS2 (0,0) on EasyDriver connected to P2_0 and P2_3 on MSP430 pinMode(P2_0, OUTPUT); pinMode(P2_3, OUTPUT); digitalWrite(P2_0, LOW); digitalWrite(P2_3, LOW); //Enable - EasyDriver Enable-Pin is connected to P1_5 on MSP430 pinMode(P1_5, OUTPUT); digitalWrite(P1_5, LOW); //Button pinMode(buttonPin, INPUT_PULLUP); }const int timing = 590; //delay in
  5. Like
    yosh reacted to greeeg in GPS logger for a local Beagle club   
    Went through and soldered up a batch of new PCBs


     
    Paneling PCBs made this process much fast.
    I'm still using my manual PnP which isn't very fast or accurate, especially after a few coffees.

  6. Like
    yosh reacted to greeeg in GPS logger for a local Beagle club   
    @Fred It would be nice to see how much of a performance gain I get with/without. The LNA is already designed to only amplify within the range of GPS + GLONASS frequencies. As mentioned just bypassing the filter with a bodge wire seems to work quite well.
     

     
    I did a very quick side by side test, and the new uBlox MAX M8Q with a 25x25mm antenna shows twice the satellites than the old g-top modules, all with improved signal strength.
     
    For reference here is a comparison of the path antenna sizes.

    (Left to right: 12x12mm, 25x25mm, 35x25mm)
     
    The 35x35mm was in stock at digikey so I bought 2 to play around with and compare. The 25x25mm is what I plan to use for this version.
     
  7. Like
    yosh got a reaction from spirilis in Custom MSP430-Board for EasyDriver   
    Hi, encouraged by @@bluehash I

  8. Like
    yosh got a reaction from qgs in Custom MSP430-Board for EasyDriver   
    Hi, encouraged by @@bluehash I

  9. Like
    yosh reacted to greeeg in GPS logger for a local Beagle club   
    The 5 units in the field have been working quite well. I've been learning alot, Typically my projects have been on the prototype scale. Even just stepping up to 5 or 10 makes you think about small optimizations in the design phase.
     
    The GPS modules were chosen because they had integrated antennas, and were cheap! (very cheap!) ($12 from Chinese sources) this helped keep the overall unit cost low. but obviously had some unforeseen issues. One of the 5 units is much less sensitive to GPS as the others, I'm scheduled to have the units back to look into this. The eratic / jerky motion of the dogs isn't what the units are designed for and ocassionally the track will "jump" by 50-100m in N/S/E/W direction for a solid 60 seconds before "jumping" back. This means the tracks recorded sometimes are not the true path the dog took.
     
    Lastly the compact design of the GPS module likely sacrifices antenna size for portability. This has also resulted in the units taking awhile to get an initial lock. Even for hot starts. (about 60 seconds)
     
    To address these issues I'm redesigning the device with some changes based on feedback from v1.0
     
    Here is a photo of the newly designed PCBs. I need 10 units, so I've made a panel of 2 so that I can leverage cheap 10x10cm prototype PCB fabs.

     
    Changes from v1.0
    Moved all components possible to backside of PCB. (These will be hand placed and re-flowed) Changed to 4 layer PCB, this means we can have a continuous ground plane behind the GPS antenna. Changed to a uBlox Max6/7/8 footprint (Plan to use the MAX8 fro GPS + GLONASS) Added solder pin GPS antenna and LNA + BPF Minor changes to passives Added inline resistors to data lines of GPS + SD to reduce noise Using split ground plane to isolate noise (not an ideal layout, but there isn't much room to play with) I have kept the same MSP430F5514 to enable cross compatible code between hardware v1.0 and v2.1
     
    PCB are at the fabs and parts have been ordered. The GPS antennas I'm using will be 25x25 which is a big step up from 12x12 on the old modules. Hopefully we see an improvement.
  10. Like
    yosh reacted to NurseBob in F5529LP + GPS MT3339 + RockBlock7 9602 Iridium Sat-Comm DIY "spot me"   
    My wife wants to know that when I do my John Muir Trail trek starting on 7/26/2016 I've not fallen down and can't get up, or been eaten by a bear...
    So, I've been building my DIY "SpotMe" Iridium Network-based GPS-Satellite Comm device. 
    I've gotten to the basic level of communication; It reports my position on a regular basis (the following is from a morning conditioning hike). 
    To my surprise, when I set the deconstructed system up on my kitchen table, it managed to both get a GPS fix AND successfully transmit the data to an Iridium satellite.  Given that there is really no "sky" visible from my kitchen, a better than expected performance! 
    Why build it when I could buy similar? Well, why not???  Similar to Dave Jones' "take it apart" I'm a firm believer in DIY to figure out how something works, and can I make one...
     
    Future travel plans: I do "Iron Butt" rides on my 2005 ST1300 - now with 175,000+ miles (there's no typo there, I've really driven that far on my bike...), and I'm planning to do 300 mile sections of the Pacific Crest Trail for the next 10 years. So, again, keeping the wife happy and "in the know."  So, this will be something I plan to use on a regular basis over the next several years.
     
    Once finished with the project I will publish all code, hex and design files for those who have an interest.
     
    Finally, thanks to all who have helped me.  Especially Robert Woodruff, yyrkoon, and Spirilis.
     
    Bob
     
    http://www.nursebobsblog.org - currently stale content, updates planned for after the hike and teaching again...
     
    On 7/14/2016 at 09:01:47 PDT Bob was here:  https://www.google.com/#q=%2B38.564295,-122.432641 -Aprx Elev.: 1676 ft
    On 7/14/2016 at 09:14:44 PDT Bob was here:  https://www.google.com/#q=%2B38.572575,-122.428550 -Aprx Elev.: 1645 ft
    On 7/14/2016 at 09:25:53 PDT Bob was here:  https://www.google.com/#q=%2B38.575296,-122.433725 -Aprx Elev.: 1644 ft
    On 7/14/2016 at 09:36:38 PDT Bob was here:  https://www.google.com/#q=%2B38.580748,-122.431888 -Aprx Elev.: 1784 ft
    On 7/14/2016 at 09:50:50 PDT Bob was here:  https://www.google.com/#q=%2B38.582575,-122.431873 -Aprx Elev.: 1743 ft
    On 7/14/2016 at 10:05:25 PDT Bob was here:  https://www.google.com/#q=%2B38.574358,-122.427476 -Aprx Elev.: 1564 ft
    On 7/14/2016 at 10:16:14 PDT Bob was here:  https://www.google.com/#q=%2B38.569375,-122.423606 -Aprx Elev.: 1740 ft

    No visible sky, from inside my kitchen:
    On 7/14/2016 at 11:34:57 PDT Bob was here:  https://www.google.com/#q=%2B38.539415,-122.471001 -Aprx Elev.: 593 ft
     

  11. Like
    yosh reacted to terjeio in Compact command parser/dispatcher example   
    A command parser/dispatcher example from my CO2 laser engraver codebase, using a struct array containing the commands and associated  pointer to functions. A lot cleaner (and easier to maintain) than switch/case statements or if/else constructs...
    Functions get called with a pointer to the command tail for local parameter parsing.
    The struct array data are all placed in flash.
    typedef struct { char const *const command; bool (*const handler)(char *); const bool report; } command; bool query (char* params); bool start (char* params); bool moveXrel (char* params); bool moveYrel (char* params); bool moveZrel (char* params); bool XHome (char* params); bool YHome (char* params); bool ZHome (char* params); bool XYHome (char* params); bool zeroAllAxes (char* params); bool laser (char* params); bool setLaserPower (char* params); bool setImageDPI (char* params); bool setPulseDutyCycle (char* params); bool enableCoolant (char* params); bool enableAirAssist (char* params); bool setMode (char* params); bool getPosition (char* params); bool setPPI (char* params); bool setPulseWidth (char* params); bool enableExhaustFan (char* params); bool setEngravingSpeed (char* params); bool getStatus (char* params); bool setEchoMode (char* params); bool setAMode (char* params); bool setPWROffset (char* params); bool loadProfile (char* params); bool setXBcomp (char* params); void exeCommand (char *cmdline) { static const command commands[] = { "?", &query, true, "Power:", &setLaserPower, true, "DutyCycle:", &setPulseDutyCycle, true, "PulseWidth:", &setPulseWidth, true, "DPI:", &setImageDPI, true, "Start:", &start, true, "X:", &moveXrel, true, "Y:", &moveYrel, true, "Z:", &moveZrel, true, "HomeXY", &XYHome, true, "HomeX", &XHome, true, "HomeY", &YHome, true, "HomeZ", &ZHome, true, "ZeroAll", &zeroAllAxes, true, "Laser:", &laser, true, "Coolant:", &enableCoolant, true, "Air:", &enableAirAssist, true, "Mach3:", &setMode, true, "Pos", &getPosition, false, "PPI:", &setPPI, true, "Exhaust:", &enableExhaustFan, true, "Speed:", &setEngravingSpeed, true, "Status", &getStatus, false, "ASelect:", &setAMode, true, "PWROffset:", &setPWROffset, true, "LoadProfile:", &loadProfile, true, "XBComp:", &setXBcomp, true, "Echo:", &setEchoMode, false }; bool ok = false; uint32_t i = 0, numcmds = sizeof(commands) / sizeof(command), cmdlen; while(!ok && i < numcmds) { cmdlen = strlen(commands[i].command); if(!(ok = !strncmp(commands[i].command, cmdline, cmdlen))) i++; } if(ok) { ok = commands[i].handler(cmdline + cmdlen); if(commands[i].report) serialWriteLn(ok ? "OK" : "FAILED")); } else serialWriteLn("Bad command"); } For further reading see http://www.barrgroup.com/Embedded-Systems/How-To/C-Function-Pointers
     
     
     
  12. Like
    yosh reacted to tripwire in MSP432 launchpad as programmer...?   
    I've done this little mod on a MSP432 launchpad so I can program the CC2650 SensorTag with it (and use energytrace too).
     
    The 1x7 0.05" headers aren't the easiest to get hold of, so I just took a standard 10-pin cortex debug cable, cut it in half and soldered it directly to J103. The connections needed are (LP -> Cortex debug connector):
     
    GND -> GNDDetect (pin 9)
    RST -> nRESET (pin 10)
    SWCLK -> SWDCLK/TCK (pin 4)
    SWDIO -> SWDIO/TMS (pin 2)
    3V3 -> VTref (pin 1)
     
    Pin 1 is marked by the red stripe on the cable linked above. Apart from making sure to read the pin numbers the right way round, the only fiddly bit is crossing over the GND and reset wires in limited space.
     
    The ribbon enters the connector opposite the key at one end and next to it at the other. It's worth checking both halves of the cable to see which gives the best cable routing for your target board.
     
    To test you can remove the jumpers from the isolation block and set the JTAG switch to external, then connect the cable to the Ext Debug header on the launchpad and try to program the MSP432 target.
  13. Like
    yosh reacted to chicken in BoostMP3 LauchPad BoosterPack   
    You guys are a though crowd today
     
    Fist of all, Herzlich Willkommen auf 43oh @@mathiasbuder
     
    I don't think that comparing this project to an off-the-shelf MP3 player is useful, comparing to an Android tablet even less so. A customer for this BoosterPack will buy it as a tool to experiment and build their own contraptions (e.g. a radio clock?).
     
    MP3 shields for Arduino are a more relevant comparison:
    Adafruit sells their Music Maker shield for $30, based on the same IC but seems to have a lot less functionality (no recording, no buttons, no optional display). Sparkfun's MP3 Player Shield is $25, again only audio out. Seeed's Grove Serial MP3 Player is $15, again no recording. There are shields on Ebay for around $10 that support recording, e.g. this one. But software support is probably much worse than with Adafruit et al.  
    So your price may be a bit high compared to the competition, even when accounting for the superior functionality. On the other hand, there's nothing like this for TI LaunchPads yet, so there can be a markup within reason. The higher the price the more you will have to justify it with very good support with beginner friendly libraries (Energia) and documentation.
     
    Given the small TI LaunchPad ecosystem, I wouldn't expect a lot of sales, even at a lower price point. Sales will most likely be driven by publishing interesting projects based on your BoosterPack that others want to replicate. Think Hackaday, Instructables, etc.
     
    My final advice after selling a few hundred of my own widgets: Don't under-price yourself. Making and selling hardware takes a lot of time and money. When your little side project happens to be a success and turns into serious work, it is important that it will pay for your expenses and then some. If it doesn't sell because it was too expensive, you at least learned something and had fun doing so (just don't fabricate 100's of them upfront).
     
    Ignoring the business side, I still think it's a nice project. I have an older version of that MP3 chip sitting in my drawer since 10+ years and never came around actually putting it to good use.
  14. Like
    yosh reacted to tripwire in SensorTag Altitude Logger   
    Recently I took a trip to the US, which offered a good opportunity to test my altitude logger by recording a profile of the whole journey there. The trace revealed some interesting details about the flights I took, and airline operations in general.

    Here's the profile for the entire trip:
     

     
    The x-axis shows elapsed time in minutes. The altitude is shown in metres, measured relative to the start of the trace (not too far above sea level). Despite that I'll be using feet as the unit of altitude here, since that's the standard used in aviation. Because the logger calculates altitude based on air pressure, it is affected by cabin pressurisation. Instead of recording the true altitude of the aircraft it gives a trace of the effective altitude inside the cabin.

    The first big peak at the blue cursor is a flight from Edinburgh to London Heathrow. Comparing the cabin altitude trace against real altitude data makes it easier to pick out the main features, so here's a chart showing this flight's altitude as broadcast over ADS-B:
     

     
    And this is a closeup showing what my altitude logger recorded for the same flight:
     

     
    The cursors mark where I think the flight started and finished, based on the fact that the plane was in the air for 70 minutes. From takeoff the pressure falls steadily until the effective altitude in the cabin is about 7000ft, at which point the aircraft is actually at 37000ft. After cruising there for 12 minutes the plane descends and cabin pressure steadily increases.

    The cabin pressure reaches ground level before the plane actually lands, so the trace stays flat for the next 12 minutes. In fact, this section of the trace is effectively below ground level while the plane approaches landing. The plane's environmental control system has deliberately overshot and pressurised the cabin to higher than ambient pressure at the destination. At the orange cursor marking the end of the flight you can see a slight increase in altitude. This is when the flight is over and the controller opens the pressurisation valve to equalise with the external air pressure.

    It seems this extra pressurisation is done before takeoff and landing to help the system maintain a steady pressure. There's a detailed explanation of the reasons for this here: http://aviation.stackexchange.com/questions/16796/why-is-cabin-pressure-increased-above-ambient-pressure-on-the-ground

    Now on to the second flight, which was from Heathrow to Dallas Fort Worth. First the ADS-B trace:
     

     
    And the altitude logger's version of events:
     

     
    Again, the cursors mark the start and end of the flight and line up with the reported duration. The "steps" along the top of the trace match up with changes in cruise altitude from 32000?>34000?>36000ft. Maximum effective cabin altitude is about 5500ft, lower than the first flight even when the lower cruise altitude is taken into account. I think that's down to the use of a newer 777 on the international flight compared to the A319 on the domestic route. Modern planes are increasingly designed to offer lower effective cabin altitudes for passenger comfort.

    The stepped flight profile is used to maximise fuel efficiency. Flying higher reduces losses to air resistance, but early in the flight the aircraft is heavy with fuel and climbing is expensive. As the fuel is burned off the optimal cruise altitude increases, so ideally the plane would climb to match. In fact the plane can't climb gradually because modern air traffic control regulations restrict aircraft to set flight levels. The best option under these restrictions is to perform a "step climb" up to a higher level when it's more fuel-efficient than the current one. The flight levels are multiples of 2000ft for flights from the UK to the US, which is why the steps are 32000->34000?>36000ft.

    Wrapping up, one of the things I hoped to test by recording this journey was high rates of altitude change. The altitude logger can currently handle rates of change up to
  15. Like
    yosh got a reaction from abecedarian in Can't Connect to Fingerprint Scanner- MSP430G2553 w/ LP project   
    Maybe just post the sketch that _you_ are actually using on the G2553 ... so we can see which pins you use etc.
    Why do you power the finger print scanner with 5v ? I would worry a little bit about this (regarding the logic levels) ...
    Maybe add a photo or a wiring scheme ... do G2553 and scanner have the same GND?
    So ... a lot of questions
  16. Like
    yosh got a reaction from bootchk in Temporary connection for SBW flashing, without socket, using pads   
    I use this (see image) ... pogo-pins and 1 mm pitch (or so) through holes (for Vcc RST TST Gnd).
  17. Like
    yosh reacted to Ekrem in cc3200 injects noise to my thermocouple reading   
    I attached two pictures. One shows the board with a red rectangle indicating the temperature measurement circuitry. On the other picture I placed a U-shaped copper piece on top of the temperature measurement circuitry. The copper piece floats, not connected to any potential because I haven't seen any change with noise level connecting or floating it.
     
      Ekrem.


  18. Like
    yosh reacted to Ekrem in cc3200 injects noise to my thermocouple reading   
    I made a metal housing surrounding my thermocouple IC and its components. This solved my issue.
     
    Ekrem.
  19. Like
    yosh reacted to Lgbeno in T-962 Reflow Oven   
    After a few years with the toaster ovens, I recently upgraded to this T-962 Reflow oven that I picked up on eBay for $184.
     
    Not sure why I waited so long, I baked my first 3 boards printed with stencils from OSH Stencil and they turned out great. Highly recommended!
     
     

  20. Like
    yosh reacted to B@tto in MSP432 and SWD   
    Hi,
     
    I designed a custom board with an MSP432, and when I did it, I thought I could use the J103 header on the MSP432 LP to program it. But after my uploads failed, I made some investigations and found that LP use a full JTAG and not SWD to program the embeded MSP432. I finally found how to change the XDS110 mode to SWD in CCS :
     

    (on the right, "JTAG/SWD/cJTAG Mode")
     
    But how to do it in Energia IDE ? The MSP432 file organization is completely different from msp430 and I simply don't know at all where it could be changed ...
     
    Thanks
  21. Like
    yosh reacted to kassovik in Underwater clock OLED.   
    My first project. Underwater clock. Used msp430g2553.

  22. Like
    yosh got a reaction from johnmarwa in GPS library for msp430g2553   
    @@johnmarwa Please have look here for a starting point : http://forum.43oh.com/topic/4966-unable-to-retrieve-complete-nmea-string-from-serial-communication/?p=44095
     
    @@Fmilburn is right ... G2553 does not have enough memory for the "standard" examples / sketches you'll find around the net (esp. those for Arduino).
     
    Try to get things started much more simple and try to find out which functions you really need (to reduce memory) ...
     
    Good luck !
  23. Like
    yosh reacted to greeeg in GPS logger for a local Beagle club   
    Realized I haven't done much work on these for alittle while. It's very close to a working product, so yesterday I devoted to push it over the line.
     
    Dissembling a my first battery allowed me to clone the wire lengths, a small amount of kapton is used to insulate the terminals and PCB

     
    A snug fit. If another version is to be made I think I'd make some small alterations to the PCB shape.

     
    Grey unit, showing the LED windows and custom molded button.

     
    I'm bad at performing regular commits. I'm trying to improve this. I hadn't even committed the final PCB layout, even though I ordered the PCBs back in Feb.

     
    Stuff that got done
    HardwareBatteries (protection + wiring) FirmwareProper KML formatting (my initial implementation put too many errors while the gps was acquiring a fix) Button hold for power on/off Better debug output Two open files (FatFS makes this super easy) Increasing GPS data rate to 2Hz (10Hz is possible with these modules, but overkill for this application I think) Enabling long file names(FatFS makes this super easy) Enabling folders on the SD card(FatFS makes this super easy) Extracting time from GPS, using it to name saved logs and file creation date/time Making LED feedback more consistent Timezone correction from GPS UT timezone Fixed LEDs blinking for USB chargers with no USB communication  
    It's been working well on my bench. I'll have to take it out for more real world testing over the next week.
    I haven't done anything with the USB bootloader concept. This will only happen if I get enough time.
  24. Like
    yosh got a reaction from umesh in ESP8266 with MSP430G2553 launchpad   
    @@umesh are you sure your ESP8266 is set to 115.200 baud? Your output looks like the baudrate could be wrong. Maybe give 57.600 or even 9.600 baud a try !?
  25. Like
    yosh reacted to reaper7 in [Energia Library] EtherEncLib for ENC28J60   
    @@chicken - as I wrote above F("zzz") is declared in WString.h as:
    #define F(string_literal) (reinterpret_cast<const __FlashStringHelper *>(PSTR(string_literal))) @@DanielPHuber - I don't know if F is necessary for MSP and even I don't go deep into it (FlashStringHelper or PSTR) if the library compiled and works
    I don't know too how (or even) this affects performance and/or memory usage.
     
    Can You tests memory usage and performance with and without "F" ?
×
×
  • Create New...