Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Reputation Activity

  1. Like
    tripwire reacted to bluehash in Members will now be warned for incorrect post content format.   
    Hello Everyone,
    Since the community is growing to larger numbers, it becomes difficult for moderators to keep editing posts that don't follow correct post etiquette.
    So far, there are only two major rules to follow about post content.
    1. Do NOT use dropbox, imgur or any other thirdparty links, if you care about this community. These links die off after a few years/months. Look around the major forums. Images dating back to 2010 are dead and the posts are useless. So please upload to 43oh.
    2. Please use the code tag to display code. It is much easier to read and you will most probably get an answer as members will at least try to browse through code. It is the "<>" button in your edit bar.
    The warning points makes it easier for us to let you know instead of spending alot of time everyday downloading and re-uploading images and editing posts. Warning points hold no value, they will not harm you. It is just to let you know. You must acknowledge the warning to continue posting.
    Thanks! Any concerns, please list them below.
  2. Like
    tripwire reacted to chicken in [POTM] dAISy - A Simple AIS Receiver   
    Finished up project documentation by adding description of software implementation and a list of future improvements.
    As I've no inkling about RF, I'm open for any input on how to improve sensitivity and lower error rate.
    And to an earlier question by @@simpleavr, below a recent annotated screen capture with more detailed maps and some action. I was located at the red X.

  3. Like
    tripwire reacted to chicken in [POTM] dAISy - A Simple AIS Receiver   
    dAISy (do AIS yourself) is a very simple AIS receiver that I developed from scratch. It is built around the Silicon Labs EZRadioPRO Si4362 receiver, using a Texas Instruments MSP430G2553 MCU for processing and the MSP-EXP430G2 v1.5 LaunchPad as development platform.

    The complete project source code and schematics are available on GitHub: https://github.com/astuder/dAISy

    Update 5/18/2015: A finished, self-contained AIS receiver based on this project is now available for purchase in my web store.
    AIS, short for Automatic Identification System, is a standard for tracking ships. Ships advertise their position, course and other information with short transmissions on specific frequencies (161.975 MHz and 162.025 MHz). More on Wikipedia.
    An AIS receiver, like dAISy, receives and decodes AIS transmissions. It then re-packages the raw data into NMEA sentences (specifically formatted ASCII strings). Finally, using a serial connection, these strings are forwarded to more capable equipment for further processing.

    If you're the lucky owner of a tricked out boat, you could connect dAISy to your navigation computer. For land lobbers like me, a more common use case is to run naval mapping software that supports AIS data input on a PC. In the screenshot below I've connected dAISy to OpenCPN (link), an open source chart plotter and navigation software.

    On the top right you can see my setup war-driving at the Seattle waterfront as my lab is too far from the coast to receive anything. The LaunchPad sits on the dashboard with a white USB cable connecting to the notebook computer in the foreground.
    dAISy's data is fed into OpenCPN, bottom right shows a log of the serial data received. OpenCPN maintains a database of all the collected data (lower left) and visualizes nearby ships on a map (top center), including past and projected course. Hovering the mouse over a ship will display its name (text on yellow ground) and clicking it will reveal more detail (top left).
    I wanted to build my own, non-SDR, AIS receiver for a long time. There are a few projects floating around the internet (e.g. here) which refer back to an article by Peter Baston, published 2008 in Circuit Cellar magazine (copy available here gone.. google for Peter Baston Circuit Cellar to find other copies). Unfortunately, the CMX family of modem ICs by CMS Microcircuits (link) used in these projects are relatively expensive ($15+) and hard to find for hobbyists. In addition you'd need a radio to do tune into and down-convert from the ~162 MHz carrier frequency.
    So I was quite excited when earlier this year a parametric search on Mouser brought up a new IC  that covered the required range (162 MHz) and modulation (GMSK). And best of all, available in single quantities for $3.56 $2.27 $2.22! (link)
    The Silicon Labs EzRadioPRO Si4362 (link) is a single chip receiver that covers frequencies from 142 to 1050 MHz and supports various modulations, including GMSK. It comes in a tiny 20-pin QFN package and the only external parts required are a 30 MHz crystal, an antenna with a few capacitors and inductors for impedance matching, and finally some decoupling caps and pull-down resistors.
    Time to whip up a breakout board. I used the opportunity to give KiCad a try and quite like it.
    Here's the schematic:

    And the layout:

    I used OSHPark to make the PCBs. At a smidgen over one square inch it cost  $5.15 for 3 copies:

    Note that the layout still has three issues that I already fixed in the schematic:
    GPIO0 and GPIO1 were flipped SDO required a pull-down resistor as the radio leaves it floating when not actively sending, which confused the hell out of me while trying to figure out the communication protocol. Lastly, the holes for the headers turned out to be slightly too small to comfortably fit the cheap breakout headers I had at hand. Edit: Here's Rev B where I fixed these issues: http://oshpark.com/shared_projects/WI6u3Qmk
    Which brings us to the BOM:
    Silicon Labs Si4362 (U1) 30 MHz crystal (X1) Si4362 datasheet specifies <11 pF load capacitance, but a crystal specified for 12pF load capacitance seems to work fine too Antenna/LNA matching network, calculated based on SiLabs AN643 (link, approx. values, +/- 5% shouldn't matter too much): 75 ohm (dipole): 10 pF (CR1), 5 pF (CR2), 280 nH (LR1), 200 nH (LR2) 50 ohm: 12 pF (CR1), 6 pF (CR2), 240 nH (LR1), 160 nH (LR2) Decoupling caps: 100 pF, 100 nF, 1uF (C1, C2, C3) Pull-down resistors 100 k (R1, R2) First thing I noticed when I received the parts: The 20-pin QFN at 4x4 millimeters is tiny!

    I mounted it by first tinning the pads with a small quantity of solder. I then added flux and placed the chip on the pad. I then used a hot air station to carefully reflow the solder. Worked the first time around.

    After using jumper wires to figure out how to talk to the chip, I mounted the breakout board on a makeshift BoosterPack using perfboard, double-sided tape and wire (see picture at the top of the post).

    Here's how I ended up connecting the breakout board to the LaunchPad / MSP430G2553:
    SEL -> P1.4 (SPI chip select) SCLK -> P1.5 (SPI CLK) SDO -> P1.6 (SPI MISO) SDI -> P1.7 (SPI MOSI) GPIO0 -> P2.0 (I/O unused) GPIO1 -> P2.1 (I/O clear-to-send) GPIO2 -> P2.2 (I/O RX clock) GPIO3 -> P2.3 (I/O RX data) SDN -> P2.4 (shutdown / reset) IRQ -> P2.5 (I/O channel-clear) Software
    The software of dAISy consists of three major blocks:
    Radio configuration and control over SPI Packet handler, including a basic FIFO for received messages NMEA encoding and transmission to the PC over UART For UART (TX only) and SPI (TX/RX) I use the MSP430G2553's USCI A0 and B0 respectively. In both cases I don't use interrupts which simplifies things considerably.
    Upon reset the following steps happen:
    Initialize MSP430 peripherals Initialize packet handler, which will also reset FIFO Initialize and configure of radio, which will also setup SPI Start packet handler, which will also put the radio into receive mode And in the main loop:
    If debug messages are enabled, poll packet handler for status and errors and report them over UART Check FIFO for new packets If there is a new packet, invoke NMEA processing (which sends the message over serial to the PC) and remove packet from FIFO Below follows a more detailed discussion of the radio integration and the implementation of the packet handler.
    The communication with the radio is vanilla SPI using 4 wires: MOSI (SDI), MISO (SDO), CLK (SCLK) and CS (SEL). I used the MSP430's USCI B0 to implement SPI and a separate pin to control CS.
    The only tricky thing to figure out was, that the Si4362 keeps the MISO line floating unless it actively transmits data. This is unfortunate as the master is supposed to poll for a specific response (FF) to detect when the radio is ready to receive more commands. This is easily fixed by adding a weak pull down resistor to SDO. I did this on the board, but it probably also works with using MSP430's internal pull-down.
    Additional lines I used to control the radio are:
    SDN to reset the radio CTS, which by default is mapped to the radio's GPIO1, indicating that the radio is ready for the next command While taking up an extra pin, CTS turned out to be much more convenient than the SPI response code to properly time communication flow with the radio. In dAISy, I wait for CTS to go high after each command to ensure the radio completed its task.
    The communication protocol is quite extensive but well documented:
    EZRadioPRO API Documentation describes the complete API and all registers AN633 Programming Guide for EZRadioPro Si4x6x Devices describes how to use the API in common scenarios Both are available on the Si4362 product page (link), under Documentation > Application Notes and are still updated quite frequently.
    The radio is set up by dumping a large configuration sequence into it. This includes configuration of radio frequency, modulation, GPIO pins and more. This information is stored in radio_config.h, which has to be generated with a tool called WDS (Wireless Development Suite). WDS is available in the Tools section on the Si4362 product site.

    Above are the settings I used for dAISy. WDS will use this information to configure various amplifiers, filters, clocks and decoding algorithms inside the chip. As Si4362 supports GMSK encoding only indirectly (see this thread), I'm certain there's more optimization potential by tweaking registers, but that's currently way beyond my knowledge of RF theory.
    While the Si4362 comes with its own packet handler, it unfortunately does not support NRZI encoding (Wikipedia). So I set up the radio to expose the 9600 baud clock and received data on separate pins and implemented my own packet handler.
    Packet Handler
    The packet handler (inspired by Peter Baston's implementation) is implemented as a state machine that is invoked on each rising edge of pin P2.2 which receives the data clock.

    There are 5 main states:
    Off, no processing of incoming data Reset, start from anew, either on start up or after successful/failed processing of a packet Wait for Sync, waiting for a training sequence to arrive (010101..) and start flag (01111110), implemented with its own state machine   Reset, start new preamble 0, last bit was a zero 1, last bit was a one flag, training sequence complete, now process start flag Prefetch, ingest the next 8 message bits to ease further processing Receive Packet, process bits until the end flag (01111110) is found or an error situation occurs Independent of state, the interrupt routine continually decodes NRZI into actual bit sequence.
    In the "Receive Packet" state there's continuous calculation of the packet CRC and some bit-de-stuffing. When the end flag is found and the CRC is correct, the received message is committed into the FIFO. If an error is encountered, the bytes already written to the FIFO are discarded. In both cases, the state machine starts anew by transitioning into RESET.
    This reads like a lot of code for an interrupt handler. However with the MCU running at 16MHz even the most complex state only uses a fraction (<10%) of the available time.
    Future Improvements
    Lastly a list of things I'd like to improve with the next version of dAISy.
    Receiving on both AIS channels through channel-hopping done 1/5/2014 Tweak radio settings for better sensitivity and lower error rate LED(s) for indicating reception of valid/corrupt packets Hardware:
    Proper antenna connector Layout PCB as BoosterPack and/or USB dongle Receiving on both AIS channels at once with two radio ICs -- edit 12/25: replaced original post with high-level project description, more detailed documentation of implementation to come
    -- edit 12/28: added documentation for hardware (here and on Github), fixed some typos
    -- edit 12/31: added documentation for software and list of future improvements
    -- edit 01/05: implemented channel hopping (change to state machine)
    -- edit 01/15: changed state machine to reflect recent changes (see post further down for details), added link to shared project on OSHPark
    -- edit 01/25: major rework of sync detection state machine

  4. Like
    tripwire reacted to chicken in [ ENDED ] Nov 2013 - Jan 2014 - 43oh Project of the Month Contest   
    Officially entering my project into the POTM contest
    dAISy is a piece of kit that can receive position data from ships.
      Detailed project description:
    Source code and schematics:
  5. Like
    tripwire reacted to chicken in Products using MSP430   
    Looks like Mikey got an update
    .. or maybe it's an older version, definitely a different revision (GlowEars v1.5)
    Still an MSP430G2553 though.
  6. Like
    tripwire reacted to chicken in Products using MSP430   
    MSP430F5259 found in the new Motorola Moto X
    http://www.ifixit.com/Teardown/Motorola+Moto+X+Teardown/16867/2 (step 15)
    There's also a beefy TI C5000 DSP involved.
  7. Like
    tripwire reacted to macegr in 3D printed G2LP and 5529LP bumpers/cases   
    Hi...I was experimenting with some cases and bumpers to protect LaunchPads as they float around on a desk or in a box of parts. The regular LaunchPad bumper is based on some existing concepts, which I used to create a new design in Autodesk Inventor. The 5529 bumper-case is the same basic idea but with a snap-on lid to protect those easily-bent pins on the top. I just moved to Dallas and need to dig out my 3D printer (among other things) in order to refine the designs a little, but should be able to post some STLs in here soon if there's interest.

  8. Like
    tripwire reacted to macegr in 3D printed G2LP and 5529LP bumpers/cases   
    Haha, was playing with the 5529 case and suddenly realized I'd accidentally designed it to allow snapping the lid onto the bottom of the case, too.

  9. Like
    tripwire reacted to chicken in [ADMIN]MSP430G2553   
    Copy&paste both into notepad and save the file. Done!
    Sorry for being a cynic, but this must be your 10th post in two days in this inappropriate style.
    1) use the topic to describe the content of your post, e.g. "how can I add uart to captouch example".
    2) don't simply throw source code at us and expect someone spending their time to do your work. Assuming you actually tried to solve the problem yourself, describe what you did and where you are stuck.
    3) If you're completely lost and don't know what question to ask, you should consider to start experimenting with the individual pieces and try to understand them first - divide and conquer.
    You will find a lot of people here that quickly answer specific questions about specific topics.
  10. Like
    tripwire reacted to bluehash in 43oh Blog Feedback   
    Thanks @@cubeberg. The scroll down is only during this month to get more entries into the POTM and for sponsor exposure. It goes away after that.
  11. Like
    tripwire got a reaction from GeekDoc in TI releasing something "game changing" on Sept 16th   
    Hang on... A $30 detector for electronic components dropped on the carpet? Now that really *is* game changing!
  12. Like
    tripwire got a reaction from tml in Cannot wake up from LPM upon ADC conversion end - please help! :)   
    Ok, it's most likely not getting into the ADC12 ISR then (unless something weird's going on with the uart_puts call from inside ADC12 ISR).
    Looking at whether the example code works correctly is probably the best thing to try next.
    It would wake the CPU up, but if the ADC12IFG0 flag is never cleared and GIE is set execution would be stuck in an infinite loop. As soon as the return from the ISR executes it would immediately retrigger. The code after __bis_status_register(LPM0_bits + GIE) in get_adc_data() wouldn't get chance to run, so it would appear as if the CPU was still asleep.
  13. Like
    tripwire got a reaction from OppaErich in TI releasing something "game changing" on Sept 16th   
    Hang on... A $30 detector for electronic components dropped on the carpet? Now that really *is* game changing!
  14. Like
    tripwire got a reaction from cde in TI releasing something "game changing" on Sept 16th   
    Hang on... A $30 detector for electronic components dropped on the carpet? Now that really *is* game changing!
  15. Like
    tripwire reacted to hlipka in TI releasing something "game changing" on Sept 16th   
    I had first go on the EVM (it arrived on tuesday): http://blog.hendriklipka.de/archives/2013/09/ldc1000_test.html
    This sensor is really sensitive (and accurate), but it is intended for small distances. So anybody thinking about using it as a metal detector will be disappointed.
  16. Like
    tripwire reacted to bluehash in Forums Down - Now Up.   
    forum.43oh.com went down today at ~18:00 EST. With @@GeekDoc's help, we found that a php error was constantly being logged into an error_log file which when reached the 2GB file limit brought the site down. File has been deleted, but the error keeps getting generated. 
    I've contacted our hosting to see if they can help identify the root cause of the error. Will keep you posted.
    Thanks for all those who contacted us.
  17. Like
    tripwire reacted to jpnorair in Why is this floating point operation eating up so much Flash?   
    A bit of a rant on double precision...
    I really don't understand the "rule of thumb" to always use double precision floating point.  I guess the rationale is: "if you don't know what exactly is going on, go with double."  For most signal processing work and graphics, single-precision does the job better-than-fine.  For financial calculations and cryptography, you need to use extended-precision integers anyway.  Even on 64bit processors, single precision floating point often runs faster because it more densely loads-up the VPU.  For example On ARMv7-a, single precision can use NEON, double cannot.  The speed difference is darn close to 4x in general programming, or 20x in tight loops.
    Anyway, that's just a rant.  I've done a ton of mathematic programming in my past, and I can think of less than five times where it made sense to use double precision.  No offense to anyone here... just a long explanation of why I default to single precision (float) in my work and why I think more people should, too.
  18. Like
    tripwire reacted to jpnorair in Budget Workbench Necessites   
    That might be a worthy hack for one of these (or anything much like it).
    KRUPS FBC4 Convection Toaster Oven, 1600-watt, Stainless Steel
    I bring up this model because I've had one for years, it is great, and I know that it has digital control.  I might try hacking it over the weekend, now that I brought it up.
  19. Like
    tripwire reacted to Mark Easley TI in NY Maker Faire   
    TI will be having a booth at the World Maker Faire in Queens, NY on September 21 & 22.  We'll be showing off some pretty awesome new additions to the TI ecosystem (*cough* *cough* New LaunchPad *cough*), stacks on stacks of BoosterPacks, Energia demos, and we'll be giving away some cool items. If you are in the area, stop by and chat us up!  Should be an amazing event.
    Aside from launching new BoosterPacks, we are working with different 3rd Parties, like our friends at Element14, to enable Makers and 43oh members to design their own.  Look out for new resources available at www.ti.com/byob in the coming months. 
  20. Like
    tripwire reacted to bluehash in TI Back to School Promotion   
    TI just emailed me about a promotion they are going to run in the coming weeks. Make sure you check their site and facebook pages.
    Week 1: MSP430 LaunchPad - $6.99

    Week 2: MSP-SA430-SUB1GHZ
  21. Like
    tripwire reacted to pabigot in GCC optimization bug?   
    1 is an expression of type (signed) int, and shifting it 15 positions left overflows the representation of a signed int on the MSP430, producing undefined behavior allowing the compiler to do whatever it wants. 

    if (P2IN&SLAVE_DATA) value+=(1U<<i); and see if that works better for you. Also look for other cases where the same problem occurs. In most situations of left shift you want the value-to-be-shifted to be unsigned.
  22. Like
    tripwire reacted to roadrunner84 in Using Subroutines as Regular Functions and Interrupt Service Routines   
    You're right, a ISR will call upon the RETI (return from interrupt) instruction, while a normal subroutine/function will cal upon the RET (return) pseudo-instruction.
    The difference is in there that a RET is a pseudo-instruction. This means that it is actually another instruction in disguise. What is actually executed is MOV @SP+,PC. Better translated as "copy the value currently at the location pointed to by the stack ponter into the program counter and then increment the stack pointer by 1 word". Since this is done after all other data has been popped from the stack, this means that the PC is loaded with the PC that was pushed onto the stack by the CALL instruction.
    On the other hand RETI is a real instruction, it does something in one go that could not be done any other way. It is essnetially MOV @SP+,SR. MOV @SP+,PC in one go. Better read as "move the top value of the stack to the status register and before its effects start, do a RET". Because the status register contains the LPM bits, they are restored (return to LPM after the ISR), but before you actually go to sleep, you restore the program counter, which does effectively let you leave the ISR and clear the stack.
    Second question: no. An attachInterrupt() will just call the given function, the real ISR (which is part of Energia) might act upon the return value from your function, but this would be part of Energia, not of the MSP430.
  23. Like
    tripwire reacted to grahamf72 in Using Subroutines as Regular Functions and Interrupt Service Routines   
    I mostly agree with you. You can certainly do a lot more in an interrupt routine than the typical "set a flag & return" that is commonly espoused. But at the same time it isn't wise to load them up with time-consuming tasks and hope the hardware scheduler will take care of several interrupts piling up. 
    In short there is no single "right way" to do things. 
    There are several considerations such as:
     - the likely frequency of the interrupt
     - how much work the background operation needs to do.
     - what happens if multiple interrupts come through before the previous one has been completely dealt with - ie, can multiple interrupts be ignored, or does every one need to be attended to.  
     - The 430's low power modes can make things interesting too - depending on the task, you can sometimes put all your functionality in the main loop, and all the ISR has to do is wake the processor from sleep.
     - RAM requirements - on uCs with very small RAM, it can be easy to chew through the stack if the main routine calls functions a few levels deep and the ISR also calls multiple levels of functions.
     - Another risk is calling code that is not re-entrant.  An example of this might be if you have an LCD module - The main routine may have called a function to write data to the LCD. Halfway through writing a sequence of data an interrupt is triggered, and the ISR also tries to write data. In this case, corruption is guaranteed. 
    Personally, while I agree that useful work can be done inside an ISR, I would prefer to err on the side of doing too little in the ISR than trying to do too much.
  24. Like
    tripwire reacted to JWoodrell in ? Launchpad V1.1 prototype build   
    hey guys, the boards and components came in for my ?-Launchpad.  I have the backside of the board populated so far, going to finish the front side tonight.

    I have the LED ?-booster built up, it was simple 2 chips and SMD female headers,  the LED matrix isn't soldered in fully yet cause pin1 isn't marked on these so I'm not sure which way around it goes yet...  stupid cheap Chinese matrix.  interestingly I will have to make a few different versions of the LED board probably because there are at least 2 different pinouts for this size matrix, and I don't know which will be more common and obtainable.  the ones on adafruit are completely different than the ones I have now.  you would think these things would have a standard pinout.

    I am happy with it so far, we'll see how everything works once i check for magic smoke leaks.   I'll post again once i get something to light up (or burn out ;P )
  25. Like
    tripwire reacted to jpnorair in [Reasonably] New MSP430 Parts   
    I was poking around on ti.com today, and I was pleasantly surprised as I noted two product families that are now public.  The datasheet and user-guide dates are not super-new, but there has been little fanfare and somehow I missed it.  Maybe the reason is because I've spent the last 6 months working mainly on Cortex-M.  But anyway...
    1. RF430F5978
    I have been working with this for a long time, in private (i.e. there are libraries and board support in OpenTag).  It's really cool, because it combines a CC430F5137 with a 134kHz passive RF IC.  One cool app you can do with it is wireless charging, but really there are all kinds of cool apps that combine passive RF for localization with long-range active RF for data backhaul.
    2. RF430FR15xH
    This is an NFC chip with a small FRAM MSP430 built right in. I have not used it, but I love NFC so it can't be bad.  
  • Create New...