chicken

Members
  • Content count

    884
  • Joined

  • Last visited

  • Days Won

    78

Everything posted by chicken

  1. This is the relevant line in radio_config.h: #define RF_GPIO_PIN_CFG 0x13, 0x1A, 0x00, 0x11, 0x14, 0x1B, 0x00, 0x00 ..which in the M4463 branch looks like this: #define RF_GPIO_PIN_CFG 0x13, 0x11, 0x00, 0x21, 0x20, 0x14, 0x00, 0x00 I have a few bare boards of the booster pack laying around. Happy to solder them up if there's interest.
  2. 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 on Tindie. 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 resistors100 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
  3. Hi Sven, I think the MSP430 side is ok. It looks like your setup is able to configure the radio, and something is received. Sync indicates, that the packet handler ISR found preamble and start flag. Did you already try the regular branch? The 4463 branch is quite stale, and it looks like I did a few changes to radio configuration and packet handler on master after the branch. Regards, Adrian
  4. Yes, message type 24 is supported. dAISy itself is not really aware of the AIS message contents. It will forward all valid AIS messages it receives. You may see fewer Class B messages than expected because: Class B transponders are much weaker than Class A, and therefore more prone to noise interference. Especially for long messages like static data. Class B messages are typically sent less frequently than Class A
  5. Happy to hear that, and thank you for the review on Tindie! I had to lookup how a Jon boat looks like With that low height, I'm surprised of the 7 miles range.
  6. Here's something new in the "I would like to play with that" category: A pico-projector in the form factor of a BeagleBone Black cape. At $99, the price isn't too bad either. http://www.ti.com/tool/dlpdlcr2000evm#0
  7. @nazmibojan your radio IC may be toast by now, so you may have to replace it. @longjohn119 thank you for the detailed report. My own knowledge about antennas is very basic. It's definitely much noisier around here in suburban Seattle. Also always interested how the receivers compare to SDRs, as basically it's a very specialized SDR. For a fairer comparison, you could try to add a bandpass filter in front of the SDRs. My 1-channel dAISy has a discrete LC filter built from SMT components, and it holds up surprisingly well to the SAW filter used on other models. In real world tests the advantage of the SAW was maybe 10% more messages. An external filtered preamp can help. I observed better range when adding this one in front of the HAT: https://store.uputronics.com/index.php?route=product/product&product_id=93 Adding a preamp on-board is still on my to-do list. I did early experiments which resulted in worse reception. However by now I know that the small dAISy is limited by noise from the USB side. I may give it a try with the HAT, which despite the integrated splitter performs as good as the single-channel dAISy, i.e. the design likely has a lower noise floor.
  8. I usually have the check for the CCA condition turned off as well. It only did make sense for single-channel receivers where RSSI level can be used for more intelligent channel hopping (didn't make much of a difference). I still suspect noise to be your main issue.
  9. Excessive power would be my guess if the receiver doesn't work anymore. The radio IC is only rated to an absolute max of 10 dBm, equivalent to 10mW. You can somewhat protect the radio with two parallel PIN diodes from RF to ground. One with cathode to GND and the other the opposite way. This clamps the signal to a maximum of less than +/- 0.7V, the equivalent of 10dBm. Though not sure how long that would help when directly connecting the receiver to an AIS transponder.
  10. Hi Rian, Is this repeatable? I.e., when you reboot dAISy it works again for a few minutes?
  11. Regarding your range problem: I program the firmware on my HATs with the debugger on the MSP430F5529 launchpad. If I don't power cycle (unplug and reconnect USB) after programming and before testing, I see elevated noise levels. I don't know the exact reason, but suspect that the JTAG traffic on USB introduces noise. Maybe there's a similar issue with the Discovery boards.
  12. Hmm, it's a while since I looked at it in detail. Channel spacing is 50KHz. If I remember correctly, bandpass was set to 20 or 15KHz. I stay away from building a transponder as there's a real risk of disrupting AIS traffic if done wrong. But if you want to go down that avenue, check out this project: https://github.com/peterantypas/ais_transponder
  13. I apologize for the slow response. Besides configuration, severely limited range can be a noise issue. You may introduce noise to the radios with the wires connecting over to the STM32. The radio_config.h for the Si4362 should be a good starting point as the EzRadioPRO chips are compatible. You can generate the radio_config files for the Si4467 with the WDS tool from Silabs: https://www.silabs.com/products/development-tools/software/wireless-development-suite Seems like they changed the file format since the last time I used it. The attached project file can be loaded with the latest version of WDS. I also attached a radio_config.h for the Si4467 that I created with this project file. I haven't tested the results though. WDS3211_si4362_revb1_direct_rx.xml radio_config_Si4467.h
  14. Hi John, Quite an impressive setup you have here. I will have to dig through your blog when I have more time. As for your questions: You are correct, the HAT can be run standalone and connected to a PC with a FTDI cable. You also can power the HAT over USB by connecting the respective wire to a 5V pad on the HAT. Serial 1 duplicates the connection that goes to the Raspberry Pi and you can connect it to any other "host" device, including an Arduino. The baud rate of Serial 1 is fixed to 38400 baud. And you are also correct regarding the I2C header. It's a straight breakout of the Pi's I2C port, without any connections to the rest of the HAT. I expected that some people want to hook up sensors, as this seems to be supported by projects like OpenPlotter. Regards, Adrian
  15. Look at the pinout in the datasheet. With the G2553, TAxCLK is only available on P1.0. I compiled a table for a few MSP430s for my CounterLib here: https://github.com/astuder/CounterLib-Energia/blob/master/README.md
  16. Good progress and tidy prototyping. Interesting observation about the beam being too narrow. I wouldn't have expected that problem with bare LEDs. Angling will be tricky without visual verification.
  17. That's a nice mock-up. Took me a while to realize that the keypad and display just sit on top of a tin box.
  18. Hi Jens, The breakout while primitive will work as well as the Si446x modules from Ebay/AliExpress. Both will get you started if in line of sight of AIS targets. But I should publish the BoosterPack sometime and update the Github project accordingly. The bandpass filter increases the number of messages received. Range can be better or slightly worse depending on your RF environment. The Si4467 does perform better than the older gen chips (e.g. Si4362-B1B). In real world scenarios the difference can be minor to significant, depending on how marginal AIS reception is. I recently started toying with the EFM32 MCUs. I hope to create a small, inexpensive and easy to integrate AIS module. I really like the dev environment and peripheral libraries. Too early yet to assess RF performance compared to the standalone radios. Regards, Adrian
  19. Now here's a set of fancy booster packs! It's a fully integrated automotive radar. http://www.ti.com/lsds/ti/sensing-products/mmwave-sensors/awr/awr-tools-software.page#tools Those rectangles on the right with wiggly traces to the IC are the radar antenna. RF magic! The "CAUTION HOT SURFACE" warning label also promises excitement. Too bad they will cost $299 according to the press release. Posting in the ARM sub-forum as the radar IC features an R4F ARM core. Though the booster packs probably work with beefier MSP430 LaunchPads too. Edit: Here's the mmWave landing page. The AWR also has the non-automotive sibling IWR, including similar booster packs. http://www.ti.com/lsds/ti/sensing-products/mmwave-sensors/mmwave-overview.page
  20. For a bit of background: Atmel AVR (the chip in the original Arduino) has a Harvard Architecture, which separates program memory (i.e. Flash) from data (i.e. RAM). It uses special assembly commands to read program memory. That's why you need to tell the compiler if you want to store a variable in Flash or access data that's stored in Flash. Most other MCUs have a Von Neumann architecture with a unified address space for all types of memory. All access to memory can use the same commands and the compiler decides on where to put things, depending on whether a variable is read-only (Flash) or read-write (RAM). To maintain compatibility with code written for AVR, Energia and other non-AVR Arduino implementations replace progmem related commands to basically do nothing without having the compiler complain too much. For the MSP430 see: https://github.com/energia/Energia/blob/master/hardware/msp430/cores/msp430/avr/pgmspace.h The warning you see is because the replacement for pgm_read_word casts your int to a short. #define pgm_read_word(addr) (*(const unsigned short *)(addr)) If you want to get rid of the warning while keeping pgm_read, you could declare your array as an unsigned short instead of int.
  21. Unless you care about portability to Atmel Arduinos, there's no need to use progmem with Energia. The compiler will put anything that's declared as const into flash memory.
  22. Depending on you environment NULL may not be defined. You can use 0 as alternative. E.g. if ( bar == 0 )
  23. I guess the forward diode is to bypass the 10k resistor when the MCU draws more than 70uA. That's a great trick to remember.
  24. 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
  25. Hi @wanliban Datasheet numbers are hard (impossible?) to hit, especially when the signal comes from a real world target rather than a piece of lab equipment. But you should definitely be able to achieve better than -70 dBm. First thing: What does -70 dBm mean in your setup? The level at which you are able to receive any valid messages? Level at which you receive 50% of all messages? 80%? Real world targets or controlled signal from an RF generator? You can find my radio_config file and software on GitHub: https://github.com/astuder/dAISy Hardware wise, keeping noise out is very important. A bandpass filter in front of the radio helps a lot. Also make sure to minimize the self-inflicted noise by having continuous ground planes in the RF section and keeping the radio away from noisy circuits (like USB). If testing with real-world signals, make sure to use a proper VHF antenna (i.e. not a short rubber duck) and keep the antenna away from other electronics (e.g. monitors or LED and fluorescent light fixtures). Also follow Silabs' procedures for RX LNA matching (AN643) and layout recommendations (AN414) I hope this helps.