Jump to content

chicken

Members
  • Content Count

    907
  • Joined

  • Last visited

  • Days Won

    85

Everything posted by chicken

  1. Overview 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). Hardware 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: http://oshpark.com/shared_projects/QUWi71r4 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. Radio 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. Software: 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
  2. chicken

    [POTM] dAISy - A Simple AIS Receiver

    Hi Chumikov, The SR162 uses a Z80 MCU and two CMX589A GMSK modems (one per channel). The radio portion looks like a superheterodyne receiver with an oscillator, crystal filters and a ton of trimable passives. See attached a picture of the insides of the SR162.
  3. chicken

    [POTM] dAISy - A Simple AIS Receiver

    Hi Varnak, The dAISy software does change the channel every so often. The code for switching between the channels start at line 329 in packet_handler.c https://github.com/astuder/dAISy/blob/master/packet_handler.c#L329 The receiver will switch to the other channel when the state is PH_RESET, which is the case after an error, successful message, or when there is no start of message within PH_SYNC_TIMEOUT (defined in line 27) clock ticks (one tick being 1/9600 second). Statistically, it will miss at least 50% of the message as it can only listen on one channel at a time. Regards, Adrian
  4. chicken

    [POTM] dAISy - A Simple AIS Receiver

    Happy to hear that 🙂 Yeah, probably keep gain to a minimum. I would go with -50 dBm or less. And no worries about Google Translate, it does a great job.
  5. chicken

    [POTM] dAISy - A Simple AIS Receiver

    The Si4463 is backward compatible, as long as the chips have the same revision (B1 in this case). The pin out depends on the breakout board that you use for your project. I don't have a screenshot as I never updated the dAISy-E10-M4463D project to the new version of WDS. dAISy requires CLK and DATA from the radio, which the 4362 config files map to GPIO2 and GPIO3. If necessary, move them to other pins as they are available on your breakout board. But don't change CTS (GPIO1) as this pin is essential for SPI communication!
  6. chicken

    [POTM] dAISy - A Simple AIS Receiver

    FYI: dAISy works in Direct RX mode. Unfortunately, the built-in packet handler of the radio IC does not work with AIS.
  7. chicken

    [POTM] dAISy - A Simple AIS Receiver

    Hi Varnak, I just pushed a configuration file for WDS 3.2.11 that I had laying around. I haven't tested it, so not sure if it works as is. https://github.com/astuder/dAISy/blob/master/WDS3211_si4362_revb1_direct_rx.xml Best Regards, Adrian
  8. chicken

    [POTM] dAISy - A Simple AIS Receiver

    Hi Ross, Yes, you can feed the serial data out of the HAT into an Arduino or ESP8266. It's 8N1 UART at 38400. You can expect a few hundred messages / minute in very busy areas down to a few per minute in quieter locations. The AIS payload is encoded into !AIVDM messages. If you want to do more with the AIS data than just forwarding it, you will have to decode the !AIVDM message and then make sense of the binary AIS payload embedded in them. You can find detailed documentation of !AIVDM and payload structure that here. As you can see, it's pretty exhaustive. If you want to process AIS messages on the Arduino/ESP8266, you likely will have to focus on a few message types. 1, 2, 3, 5, 18,19 are the most important for tracking ships. This here is an Arduino library for AIS decoding that I found, but I never used it so can't vouch for it. Happy to share logs of real-world AIS data if that's helpful. If interested, send me a PM. Regards, Adrian
  9. chicken

    [POTM] dAISy - A Simple AIS Receiver

    PS: Forgot to answer the second part of your question. All the variations of dAISy are suitable for something built around a Raspberry Pi. The HAT is the obvious fit, but the USB receivers work as well. The USB receivers have the added benefit, that you can also use them on a regular PC or laptop if you decide to move away from the Pi.
  10. chicken

    [POTM] dAISy - A Simple AIS Receiver

    Hi Ross, The best solution depends on what you want to achieve. If you want to build a chartplotter, then OpenPlotter or a standalone setup of OpenCPN would be a viable approach. Both will require a RPI 3 as the GUI of OpenCPN ps For OpenPlotter, I recommend the 1.0 image and not their latest alpha, unless you know what you're doing. For standalone OpenCPN, this tutorial worked for me. If you only want to track ships and may report to a website, then AISHub's rPiAIS is the quickest way to get up and running. More DIY alternatives are Kplex (which OpenPlotter uses under the hood) or some form of home-brew Python script. ais-forwarder to send received AIS messages over the network simpleAIS to decode AIS messages in your Python project You will find more AIS related projects under my Github stars. Best Regards, Adrian
  11. chicken

    [POTM] dAISy - A Simple AIS Receiver

    Hi @pileoni You can use a terminal program like Putty on Windows to connect to dAISy. Pressing ESC will bring up a debug/configuration menu. There, you can start a test mode by pressing T and then ENTER. dAISy will start outputting an AIS message every 5 seconds. Alternatively, while in regular receive mode, you can send & to get dAISy to respond with its serial number. Let me know if this helps. Best Regards, Adrian
  12. chicken

    [POTM] dAISy - A Simple AIS Receiver

    Hi @andimmike15 To debug the application, I'd go through the following steps: 1. Write something on the serial console to make sure that end works (uart_init, uart_send_string) If that doesn't work, search this forum for tips on setting up serial output from your model of the LaunchPad. 2. Read the Si4362's part information and compare it to what's expected per datasheet (radio_setup, radio_part_info, radio_buffer.part_info.part_msb, radio_buffer.part_info.part_lsb) If you don't get the expected values (e.g. 0x43 for the msb, 0x62 for the lsb if you're using an Si4362), then something with the SPI connections is wrong. 3. Toggle LEDs in strategic locations in the packet_handler ISR, to see whether raw data and clk bits from radio arrive at the MCU and the interrupt is invoked. If that doesn't work, check that the correct radio and GPIO pins are connected. If all the above works, then you're ready to worry about the actual AIS signal. That side is hard to simulate without an AIS target, but your transponder would be a good start. But be careful to not damage the Si4362 with a too strong signal. Directly connecting the transponder with the receiver will destroy the receiver. Let me know if this helps, or where on that list you get stuck.
  13. In case you need to stock up on MSP430 dev boards, it's MSP430 week in the TI store. http://www.ti.com/store/featured/msp430week18.html
  14. chicken

    [POTM] dAISy - A Simple AIS Receiver

    For all you AIS home-brewers out there: I've added the TAI-SAW TA0395A SAW filter to my Tindie store. https://www.tindie.com/products/astuder/tai-saw-ta0395a-saw-filter/ This bandpass filter covers 6 MHz in the marine VHF band and can be found in many commercial AIS receiver and related equipment. As often with parts from specialist vendors, it is hard to come by without writing an RFQ and/or begging for samples. So I thought I'd sell some of my stash to fellow tinkerers.
  15. chicken

    [POTM] dAISy - A Simple AIS Receiver

    Hi @andimmike15 AIS messages can be longer than 32 bytes, for example message type 5 which includes the ship's name is 424 bits / 53 bytes. http://catb.org/gpsd/AIVDM.html#_type_5_static_and_voyage_related_data You could filter messages to only receive the position messages (types 1, 2, 3, 4, 9 and 18) by evaluating the message type at line 261 and resetting the packet handler state machine in case of an unwanted message. Keep in mind, that while the received message is converted to NMEA0183, a new AIS message may start arriving. So allocate a few bytes more for the FIFO than the minimal message length (21 bytes for the above, so maybe make the FIFO 32 bytes long). Note that due to its current implementation, the FIFO length must be a power of two. Setting FIFO_PACKETS to 2 is the minimum, again because a new packet may arrive while the first isn't fully processed yet. Another big chunk of memory is in the NMEA encoding section. If filtering AIS messages, you can squeeze out a few bytes by limiting the maximum size of the NMEA payload to 21 bytes (nmea.c line 19), which translates to a NMEA output buffer of 43 bytes. You could shave of a few more bytes by not storing the AIVDM lead-in in the buffer but directly outputting it on serial. Still, squeezing everything into into 96 bytes of RAM will be quite a challenge. The MSP430G2553 has a luxurious 512 bytes.
  16. chicken

    [POTM] dAISy - A Simple AIS Receiver

    The radio will work with any MCU. But in my project, you will have to rewrite anything that's hardware dependent. From top of my mind, that's spi.c, serial.c, GPIO interrupts in packet_handler.c, plus any interaction with GPIO like LEDs etc.
  17. chicken

    [POTM] dAISy - A Simple AIS Receiver

    Yes, you can remove both and it will still work. #define TEST would enable extra code. I used that during development for testing the NMEA code without a radio. As long as the project does not define it, the test code will be skipped. It's not enabled in the code, so you don't have to worry about that. #define DEBUG_MESSAGES is useful to get more information about the radio communication. I would leave that in until you got the receiver working, as it will help you tracking down what's going on.
  18. chicken

    [POTM] dAISy - A Simple AIS Receiver

    @andimmike15 For debug messages, simply add a #define in main.c, like I did on line 20. For test mode, I made a separate profile in the CCS project, which sets the define with the -D compiler option.
  19. chicken

    [POTM] dAISy - A Simple AIS Receiver

    FYI @Fonsin and @GeoffH The NMEA adapter is now back in stock on Tindie and in our own store: https://www.tindie.com/products/astuder/nmea-0183--rs-422-adapter-for-daisy/ https://shop.wegmatt.com/products/nmea-0183-rs-422-adapter-for-daisy
  20. chicken

    [POTM] dAISy - A Simple AIS Receiver

    Hello @NsNcc I'm not much of a Linux wizard, so I don't have a better method to achieve this. There was a thread on the Kplex Google group about issues with the dAISy USB because Linux didn't initialize the USB ports early enough, but I wasn't aware that the same issue exists with the regular serial port. https://groups.google.com/forum/#!forum/kplex Kplex may be overkill if you just need to forward AIS data to a network address. Alternatives are: A simple python script: https://github.com/jaluebbe/ais-forwarder Or a shell script: But of course, that still leaves you with the "run at startup problem". As a Linux noob, I'd try this (which looks very similar to what you're already doing): https://superuser.com/questions/155476/how-do-i-make-a-script-run-upon-startup-of-the-ubuntu-machine
  21. chicken

    [POTM] dAISy - A Simple AIS Receiver

    Hi @GeoffH I just sent out a request for a quote for a few more of the NMEA add-ons for the small dAISy. It will probably be 4-6 weeks before they are back in stock. I tried to directly connect dAISy TX to the A2 and GND to B2 on the NMEA2WiFi, but it does not have enough power to drive the signal. If you are into tinkering, you can try something like this:
  22. From time to time, threads pop up where someone tries to count very fast pulses in the hundreds of kHz or even MHz range. There is a solution for the hardcore C-coders among us, but to my surprise there was no Energia library for this simple problem. I herewith present the CounterLib for Energia Download Source code and detailed instructions are also available on GitHub: https://github.com/astuder/CounterLib-Energia Currently the library supports MSP430G2553, MSP430F5529 and MSP430FR5969. To create an instance of the counter, simply declare it as a global variable like this: Counter<> MyCounter; // create a counter that counts pulses on pin P1.0Once created, the counter has 5 functions:start() initializes the timer peripheral and I/O pin and starts the counter stop() stops the counter, but does not reset the counter value read() reads the current value of the counter reset() resets the counter to 0, the counter keeps running readAndReset() reads the current value and resets the counter to 0 And a basic example, which should work for signals lower than 65 kHz: Counter<> MyCounter; // create counter that counts pulses on pin P1.0 void setup() { Serial.begin(9600); MyCounter.start(); // start counter } void loop() { MyCounter.reset(); // reset counter to zero delay(1000); // wait one second Serial.println(MyCounter.read()); // read number of pulses during the last second delay(1000); // wait another second } The library also supports dividers to measure much faster signals. For more detailed instructions see GitHub. The library uses the external clock input of the timer peripheral. This enables the library to measure very fast signals (MHz range). On the downside, each timer only has a specific pin assigned, and the G2553 only has one timer with an external pin. It is also possible, that other Energia libraries or built-in functionality use the same timer, which won't work. Here's a list of the timers supported by the library and their pins: | Timer | G2553,| | | | | | G2452,| F5529 | FR5969 | FR6989 | | | G2231 | | | | |------------|-------|-------|--------|--------| | CL_TimerA0 | P1.0 | P1.0 | P1.2 | P1.2* | | CL_TimerA1 | n/a | P1.6 | P1.1* | P1.1* | | CL_TimerA2 | n/a | P2.2 | n/a | n/a | | CL_TimerB0 | n/a | P7.7*| P2.0* | P2.0 |Pins marked with * are not broken out on the LaunchPad or are difficult to access. The library probably works on many other MSP430's, but you'll need to adjust the #defines in the library. Please report back if you successfully tested with other devices, so that I can extend the library. Please report any bugs. And also let me know if you break any speed records. So far I only tested it up to 750 kHz. Edit 9/3/15: Added support for FR5969. Thanks @@Fmilburn Edit 9/4/15: Refactored to make it easier to add more MCUs. Several bug fixes, thanks to all the eagle-eyed members of 43oh Edit 3/13/16: Replaced attached ZIP file with link to GitHub to always give up-to-date version
  23. Shouldn’t there be a special badge on 43oh for earning 430 reputation points? Well, congrats to my dear friend @Fmilburn for having crossed that line of 43oh awesomeness
  24. chicken

    [POTM] dAISy - A Simple AIS Receiver

    Hi Fonsin, Glad to hear that you successfully upgraded your dAISy USB. As for the NMEA-0183 adapter: I didn't plan to build new ones as I think the 2+ is the more robust solution. But there were recently a number of requests from current owners of the dAISy USB, so I will probably spin a small batch in the next few months. It seems like the NMEA-0183 listeners are not too picky. Some (e.g. Garmin) even use just one data wire, which may directly work with the UART output on TX. Though input protection may be an issue. On my adapter I use the TI UA9638, which is also available as DIP package (UA9638CP) http://www.ti.com/product/UA9638 This IC is very easy to use. Just connect 5V, GND and TX, and you get a RS-422, i.e. NMEA-0183 compliant, differential output. And maybe add a 0.1uF and/or 1uf capacitor across the power pins if you want to get fancy. The downside of the UA9638 is, that it's relatively power hungry (50mA) compared to the rest of dAISy USB. It is responsible for 75% of the increased current consumption of the dAISy 2+. There are other RS-422 drivers which seem to be lower power, like for example the ST485 or MAX485. But I haven't used any of these. This document goes into great detail about the electrical characteristics of NMEA-0183: http://www.actisense.com/wp-content/uploads/2017/07/NMEA-0183-Information-sheet-issue-4-1-1.pdf Best Regards, Adrian PS: As for logic gates, the 74HC00 could be a good alternative for the transistor. It depends a bit on the required current, but the NMEA-0183 spec says 2mA per listener, which a logic gate should be able to deliver. Another option is to use 74HC04 to create a true differential signal (1 inverter for one line, and 2 inverters in series on the other line).
  25. I finished up my first Energia project, a template library for the Bosch BMP085 temperature and pressure sensor. It uses I2C and supports temperature in Celsius and pressure in Pascal. https://github.com/astuder/BMP085-template-library-Energia I connected the GY-80 breakout commonly found on eBay, but it should also work with most other BMP085 breakouts, like the ones from Adafruit or Sparkfun. Note that I had to patch Energia to make 1-byte read work on MSP430G2553 with Rev1.5 LaunchPad. I also had to remove the LED2 jumper, probably due to too weak I2C pull-up. Update: Tested on LaunchPad 1.5 with MSP430G2553, StellarPad Rev A and Arduino R3. Energia requires patches 226 and 235 in twi.c for I2C to work properly on MSP430G2553 https://github.com/energia/Energia/pull/226/files https://github.com/energia/Energia/pull/235/files Updates: - Tested with Energia 0101E0010 with MSP430G2553 and F5529, no more I2C patches needed. - Tested with BMP180 and Software I2C http://forum.43oh.com/topic/3777-energia-library-bosch-bmp085-template-library/?p=44410 - Fixed I2C for Energia 0101E0016 by removing ugly hacks from the past from the library code. Tested only with MSP430G2553
×