Quantcast
Channel: The Sync Channel Blog
Viewing all 38 articles
Browse latest View live

Measuring Time Takes Time

0
0
Here's a little bit of data on the Denuo GPS in a REF-0 during the warm-up period.

Classic "lots of zeros" picture of the REF-0 10MHz output.
Does this shot have much meaning? Not really.

I've been collecting phase data on the REF-0 and Denuo GPS as the pair warms up. My equipment is quite limited, and it's difficult for me to collect useful frequency data in the E-13 range. So I thought I'd just measure the phase difference between the REF-0 PPS and a stock REF-1 with the Oncore GPS. Perhaps measuring the two relative to each other will provide some insight on how a REF-0 performs with a non-timing GPS.

No data was collected for the first two days. I did monitor it casually on the counter, and it was exactly as you'd expect. Lots of big swings and settling.

Below are traces showing T + 48 to 72 hours, and T + 72 to 96 hours.

Notice the "pop" of noise during day three of the warmup.

Make sure to notice the scale when comparing this plot to the first one.

It's difficult to know what's causing what in these plots. The REF-1 has a 15 year old GPS receiver. The REF-0 has a non-timing GPS with no position hold, but great sensitivity. Better references and lots more time will be required to know more.

Though, something interesting happens when you overlay the two plots.

Plots from two consecutive 24 hour periods shown together.

The consistency between them in many spots is easy to see, even though the traces are separated by exactly 24 hours from each other. Especially during the middle of the plot, which would have been the overnight hours, the two follow each other closely. I'm not sure if there's actually anything useful to glean from that.

That's all for now. There's not much data yet, but any comments are welcome. We'll see how the unit does after a week of being on, then a month, then.... 

Thanks for reading!

- Dan W.


PCB Progress on the Tria GPS

0
0
Lots of progress today on the Tria GPS board. I got the PCBs back and assembled the first one. So far it tests out good.

SMT is so clean. My least favorite part of assembly is
soldering on the through-hole bits.

Now begins the long process of completing, testing, and verifying the firmware...

- Dan W.

Tria GPS Success in the REF-0

0
0
I made some good progress yesterday on the Tria GPS firmware. I have been finding and fixing little bugs over the past few days, and finally got to the point where I could test my Oncore message formatting routine. This is an entirely new chunk of code that creates Oncore message strings in real-time using data sent from the U-blox GPS. That is a very different approach from my previous REF-0 standalone techniques, which used canned strings to make a REF-0 lock up. I am now sending real data in all of the messages, including SV info, position, date/time, and configuration settings.

I dropped the Tria GPS into a REF-0 and launched SatStat to view the status screen. To my slight surprise, nearly everything was populated correctly. I had to make some minor adjustments, but the new Oncore message formatting routine is a success. Here's a screen capture of SatStat for the REF-0 with the Tria GPS:

Status Screen for a REF-0 with the Tria GPS

The SV info is little wonky. Partly that is because I have to adapt satellite info for a 16 channel receiver to 8- and 12-channel messages. I plan to do some more sorting to ensure that the top 12 SVs that the U-blox has acquired appear in the status screen of the GPSDO.

With my message formatting routine working, I am closer to the end goal of full Oncore compatibility. I now need to write some code to allow the GPSDO to send commands to the Tria GPS and configure it. Once that is done, I will be able to make a REF-1 lock up using the new GPS. That will be exciting.

Thanks for reading!

- Dan W.

Simulating GPS Week Rollover with the Tria GPS

0
0
GPS week rollover is an interesting "bug" in the way GPS keeps track of the date. Rollovers are not frequent, but when they do occur, it is possible for equipment reliant on a GPS lock to malfunction. At the very least, equipment made on one side of a rollover may not correctly display the date after the rollover. There are many articles online that cover the issue in-depth, so I won't attempt to explain it here. These are some links:


GPS week rollover can be a problem on older surplus timing gear that is still in operation. The user may have to reset the unit after a rollover, or deal with an incorrect date display. As the Tria GPS module I am designing is meant for use in just such a unit, the Lucent KS-24361, I decided to do some experimentation on the rollover issue with this box. The Tria GPS has a simple text-based user interface over a serial UART, so I added a GPS week rollover simulation to the available options. After this is selected and the unit is power cycled, the GPS module fast-forwards the date and time to 30 minutes before midnight, April 6th, 2019 to simulate the next rollover.

I used a REF-0 for these tests.

Tria GPS warning the user that the simulation is in progress.

Here's the view in SatStat.
Synchronized to GPS time all right... 4 years in the future.

Simulating this on my board is actually very easy to do. I have complete control over the Oncore serial strings and what I send the GPSDO, so changing the date is just a slight modification to the initialization routine.

As the time approached "midnight", I connected to the U-blox LEA-6T module in u-center and ended the automatic survey early. This way, we could hit midnight in normally operating conditions. Being able to modify GPS settings in u-center is a really nice feature of the Tria GPS.

Changing GPS configuration settings in u-center, and seeing the results in SatStat.

For this simulation, I programmed the module to roll the date back to August 1999 at midnight. That, of course, was when the last rollover occurred. Here I am simulating a GPS module that was built between the rollovers and can't display dates beyond April 6th, 2019.

The simulated rollover just occurred. Will the REF-0 handle it ok?

Well, as you may have expected, nothing dramatic happened. I have found the KS-24361 units to be very tolerant of date/time "mishaps". They simply reset their internal clocks after a minute or so when a significant change occurs on the date/time presented in the serial strings. After the rollover, the unit displayed the wrong date, but never threw an alarm or lost lock.

The REF-0 continues to operate normally after the rollover. However, it now shows
the incorrect date that is being sent to it.

If I can inject a problem with the Tria GPS, I can also fix the problem. U-blox modules handle GPS week rollover pretty well, and of course the RTC in the Tria GPS understands more than 1024 weeks. So it's very possible to "fix" the rollover problem and just send the GPSDO the correct date after April 6th, 2019. I modified my simulation routine to do this with good results.

Here the Tria GPS and REF-0 have rolled over to April 7th 2019 with no ill effects.

This sent me on a quest to determine the actual date range supported by the KS-24361 firmware. Is it effectively unlimited, and the only limitation is the GPS module? Or is there some other date rollover we will eventually hit on these units? I simulated dates further in the future and went all the way up to 2038 with no issues. That's when I ran into the 2038 bug in the C time library I am using. Sigh...

We really broke the date on the Tria GPS and REF-0 trying to go past 19 January 2038.
But this is due to a very different rollover bug.

2038 is a long way off, so I'm not going to worry about that one right now.

By this point, dealing with leaps into the future, two different date rollover bugs, and the outer limits of the C time library had given me a headache. I was quite happy to reset the clock to the correct time and wrap things up.

Summary

Playing around with GPS week rollover simulation was an interesting experiment. In the end though, the Tria GPS makes the whole thing a non-issue. One of the many benefits of upgrading to a modern GPS receiver from the Oncore UT+ receivers is that we can better handle things like GPS week limits and leap seconds. This should keep old GPSDOs operating well past the next "rollover".

Thanks for reading!

- Dan W. 

Distractions

0
0
If I don't stop getting distracted, I'll never finish the Tria GPS firmware. Hmm...


- Dan W.

Denuo GPS Hits Rev B + Dongles...

0
0
This is a quick update on the REF-0 projects I have going.

REF-0s running my Denuo GPS board. All lights green.

The Denuo GPS has hit Revision B. There were very minor changes to the original board, mainly to tweak the BOM. I have also hit firmware version 0.6, which I feel is very stable and reliable. There is always room for improvement, but I am close to calling the firmware "done".

I have also been thinking on what a Denuo GPS retrofit kit for the REF-0 would look like. One of the important steps in prepping a REF-0 for standalone operation is eliminating the need for the interface cable. I have covered multiple techniques for doing this in my previous posts. However, a kit would have to be as simple as possible to install. Looking for unlabeled pins on the bottom of a PCB and soldering fine bodge wires is not a good installation method. Neither is jamming wires into a DB15 socket. For that reason, I made this:

A dongle to replace the interface cable on the KS-24361 units.
It is effectively a "magic dongle" for the KS-24361. It jumpers the necessary pins to eliminate the other box and the interface cable. Plug it into a REF-1 and the unit turns on the outputs and operates standalone. Plug it into a REF-0, install a replacement GPS internally such as the Denuo board, and it hums away all by itself.

There will still be soldering involved in any REF-0 retrofit. But this dongle should greatly simplify things.

As for the Tria GPS board, that project is coming along slowly but surely. Attempting to implement Oncore UT+ compatibility is a big undertaking, but I've made good progress. I have a solid plan to get to the finish line.

That's all for now. I should have something interesting to post about in a week or two. It's a brand new project involving...FPGAs.

Thanks for reading!

- Dan W.

Helping Your Feathers Flock Together

0
0
This post is about the Adafruit Feather line of microcontroller development boards. It will serve as a guide to cross-Feather compatibility when designing both hardware add-on circuits and software to work with all of the Feather variants.

Left to right: Feather 32U4 Adalogger, my GPS FeatherWing, Feather M0, and Feather HUZZAH.

Introduction

Occasionally I see a new product or microcontroller development board that really sparks my interest. That's what happened with the Adafruit Feather line of boards. They pack a lot of punch into a small footprint, especially when you consider the fact that LiPo charging is built-in, as well as Wi-Fi, Bluetooth, or an SD card on some of the variants. Adafruit is also releasing expansion boards called FeatherWings, which are like Arduino shields or Beaglebone Black capes. I immediately had a project idea involving GPS and data logging, but the GPS FeatherWing wasn't out yet. So, I fired up Eagle and designed my own.

Compatibility Issues

I designed a FeatherWing using the U-Blox NEO-6M GPS module. I've used it many times before in other projects, and it's very easy to work with. It fit perfectly on the board along with it's supporting circuitry. I had some space left over, so I decided to add a sensor. On one version of my board I had a simple temperature sensor, and on the latest version I have a 3-axis accelerometer. When I designed this board, the Feather 32U4 (basically a smaller Arduino Leonardo) was the only one out, and not a single FeatherWing had yet been released. I had to make some guesses about compatibility in the pinout. Well, my board works great with the Feather 32U4 and it's Adalogger cousin.

But... I have had to make some changes to support the recently released Feather M0 and Feather HUZZAH (ESP8266). It's clear that Adafruit had to make compromises to fit so much hardware on such a small board, and this is very apparent when you start looking at the pinouts. Not all of the standard Arduino digital pins are broken out, and some have dual functions. The HUZZAH in particular has several pins that have to be used in certain ways or avoided all-together to prevent bootloader problems. Below, I will document what I discovered and list my recommended pin usage for your projects that will work with any of the currently-released Feather boards. It's an important consideration when soldering your proto-board connections or designing your own PCB that will of course have a fixed physical pin arrangement.

UARTs

Serial communication on the Feather 32U4 is pretty simple, and your Arduino projects can probably transfer straight over. You have the hardware UART on pins D0 and D1. Also, you can use SoftwareSerial in the IDE to turn other digital pins into serial pins. On the M0, things are a little different. SoftwareSerial is not (currently) supported. However, you have several SERCOMs available that can act as hardware UARTs. They are somewhat documented in this post on the Arduino forum. Great! Right? ...

Unfortunately the SERCOM pins don't line up well with the usable pins in SoftwareSerial for the Feather 32U4 (basically a Leonardo in the IDE). For example, SERCOM1 uses pin D12 as RX, but that is not a possible RX pin in SoftwareSerial on the 32U4.

Serial communication is once again different on the HUZZAH. You do have the hardware UART that lines up with pins D0 and D1 on the M0/32U4, but you should really (really) leave that one alone. It's connected to the serial bridge, and you don't want USB traffic interfering with your serial-connected device or vice versa. There is a second hardware UART in the ESP8266. It's documents on the github ESP8266/Arduino page, but you can see just the relevant part in this post on the ESP8266 forum. That UART would work fine with a 32U4-compatible pinout, but doesn't work with the SERCOM pinout on the M0.

So what to do if you need a second non-USB UART? My recommendation is to use pin D10 on the 32U4 and M0 (pin #15 on HUZZAH) as a second serial RX. That will work with the M0 SERCOM and 32U4 SoftwareSerial, and there are some SoftwareSerial-like libraries out there for the ESP8266 (1, 2, probably more...) that should work for your project. For the TX line, I recommend implementing a jumper in your circuit to select between pins D11 and D12 (pins #12 and #13 on HUZZAH). Select the pin D11 jumper to use the SERCOM on the M0, and select the other jumper for 32U4 and HUZZAH.

Interrupts

For using the AttachInterrupt routine in the Arduino IDE, the possible pins on the 32U4 and M0 are documented on the Arduino AttachInterrupt page. (Look for "Leonardo" and "Zero" respectively in the table). For the ESP8266, they are pretty much documented here (along with a ton of other information). What is not frequently mentioned in the resources I saw is that pin #16 on the ESP8266 is not usable with AttachInterrupt.

You really can't find a common interrupt pin that will work on all of the Feathers. That is kind of a bummer. If you need interrupts, I recommend designing around the M0 or HUZZAH. As a fall-back if you hook your circuit up to a 32U4 Feather, you can use a while loop in the main loop to watch for the pin level to change. That's far less useful than an interrupt, but it might get you by for your project.

Analog Input

Analog input on the 32U4 and M0 is super easy. You have the standard A0 through A5 pins we are all familiar with from the Arduino boards. (A0 on the M0 board is also the DAC output!) There are other analog inputs possible on some digital pins. The HUZZAH is very different though. There is only a single analog input (at the A0 pin position), and very importantly, it has a MAXIMUM input voltage of about 1 Volt. That limits it's usefulness when designing for cross-Feather compatibility. You could use a voltage divider to drop the input voltage to a safe level, but that will likely limit your resolution on the 32U4 and M0 boards unless you can tolerate a different analog reference voltage (AREF).

Digital I/O

There are some things to be aware of on the digital pins of the Feather boards. Pin D9 on the 32U4 and M0 should be avoided, because it is connected to a resistor divider to read the battery voltage. Also, pins D2 and D3 on the 32U4 board are in the same positions as pins 20 and 21 on the M0 board. That's because they are the I2C pins. I would suggest reserving those pins for I2C instead of wasting them on digital I/O. There seem to be lots of cool official FeatherWings coming out that use I2C exclusively to add functionality.

Digital I/O on the HUZZAH is once again very different. The pin numbering is different from the 32U4 and M0 boards, so it makes it difficult to refer to particular pins between the variants. Some of the pins are used in the bootloading process. You can read more about it in the official Adafruit tutorial. Long story short, just avoid pins 0, 2, and 15 if possible. You can use them as outputs as suggested in the guide, but you also need to consider the state of the pins on initial boot-up. I noticed some very strange behavior on my FeatherWing board when trying to use those pins, and certain connections would completely prevent programming or booting of the board. Three good digital I/O pins to use are #14, #13, and #12. However, those are also used for hardware SPI (and connected to the SPI pins on the opposite header). You might have to sacrifice SPI in order to get some "clean" digital pins for your project on the HUZZAH.

What does it all mean?

Wow, that was a lot of information. If you examined all of the links I posted, you'll see why I hit so many roadblocks in finding a good cross-compatible pinout for my FeatherWing board.

My over-arching recommendation is to pick one Feather and design around it. That will help you extract the most from the available pinout. However, the point of this article is finding a cross-Feather-compatible pinout so you can swap your circuit or custom FeatherWing between boards.

So, let's summarize the key points and mention some other tidbits:
  • Reserve the I2C pins in your project and don't waste them on regular digital I/O. I2C seems to be the primary way to add functionality to the Feathers due to the limited pin availability.
  • For a second UART, I recommend using pin D10 (#15 on HUZZAH) as serial RX and implementing a jumper to choose between pin D12 for the M0 and D11 (#13 on HUZZAH) for TX. Your sketches will be different for all three in order to set up the necessary configurations or libraries.
  • You are pretty much out of luck for a common interrupt pin between all three boards (assuming you have the requirement that the main UART and I2C pins be left alone). I have found pin D5 (#2 on HUZZAH) to be a possible option. It works with AttachInterrupt for both M0 and HUZZAH. However, it does have a pull-up resistor and LED attached to it on the HUZZAH. Make sure that your circuit won't pull it low on boot-up, and can tolerate the pull-up. For the 32U4, you would have to check the level in your code (not a true interrupt).
  • Analog inputs: If you only need a single analog input, you can put a voltage divider on it to knock the MAX input level down to 1V and connect it to A0. This will work on all three boards, but potentially with reduced resolution on the M0 and 32U4. Also, you sacrifice the DAC functionality on Feather M0 (it uses pin A0). If you need more than one analog input, you might have to consider adding an ADC chip to your circuit that talks to the microcontroller over I2C for the HUZZAH.
  • If you are designing a custom FeatherWing specifically for M0 and 32U4 and plan to use 3.3V analog inputs, use pins A1 through A5 only. This prevents the situation where someone connects the FeatherWing to a Feather HUZZAH and a signal above 1 Volt on A0 damages the ESP8266 module.
  • Be very cautious when selecting your digital I/O. The HUZZAH in particular has multiple pins that affect the bootloading process and have LEDs/pull-ups connected to them. Pins #14, #12, and #13 (D13, D12, and D11 on M0/32U4) are good options as long as you don't need to use SPI.
  • About pin D13... It is connected directly to an LED and resistor on the Feather M0 and 32U4. You need to keep that in mind when attempting to use it as a digital I/O pin (especially as an input). On the HUZZAH, it is a "clean" pin (the LEDs are on pins #0 and #2).
  • If you want to design your own FeatherWing, watch out for the pin next to D0 and D1 on the M0 and 32U4 boards (labeled as a Ground pin). On the Feather HUZZAH, driving that pin low will hold the ESP8266 processor in reset! Therefore, that pin needs to be treated as a No Connect. There is a primary Ground pin next to the AREF pin.
  • The Feather boards do not have I2C pull-up resistors on-board. Remember to add them to your own circuit if you are using I2C.
Summary

I hope the information I have presented here is useful for finding a pinout for your project that will work across all three Feather boards. Again, I would not suggest going that route if you can avoid it. Pick one Feather and design around it to get the most from the I/O pins. However, if you really want a circuit or custom FeatherWing that works on all three AND uses several types of I/O, there are a lot of things to watch out for.

As always, the official Adafruit documentation about Feather should be your main resource. Please post any comments and corrections below.

Thanks for reading!

- Dan W.



Exploring the I/O Performance of the Arduino 101

0
0
In this post I will explore the hardware input/output (I/O) performance of the recently-released Arduino 101.

The new, yet somehow familiar, Arduino 101.


Introduction

Though many of my personal projects have moved beyond the Arduino eco-system, I still enjoy keeping up with the Arduino line of boards. The newly-available Arduino 101 is a very intriguing addition to the line-up. It packs an Intel Curie system-on-chip (SoC), Bluetooth Low Energy (BLE), and a six-axis accelerometer and gyroscope. Despite these new features, it only costs $30 USD and is surprisingly familiar to hold in the hand. The pinout is similar to an Arduino Uno, with power, digital I/O, and analog inputs in the usual places.

The Quark microcontroller inside the Curie SoC runs the ViperOS real-time operating system (RTOS), which Intel is promising to open-source at some point. That will present some intriguing options for advanced hobbyists and developers to extract maximum performance from the board. For now, we can program it using the Arduino IDE. As I understand it, you don't really "flash" an Arduino 101, but rather upload a new sketch for the RTOS to execute itself.

Though the Arduino IDE makes developing code for projects very easy, it also imposes performance penalties. This is especially noticeable when you are trying to stretch the limits of the I/O. I just unpacked my new Arduino 101. Before delving into the example projects for the board or attempting to port some of my previous projects over, I thought I'd have a look at the performance of the board's I/O lines.

5V Tolerant?

Here's the big question many will ask: Are the I/O pins 5V tolerant? Well, yes they are. Arduino says that the I/O lines on the 101 are 3.3V, but will not be damaged by 5V inputs. Clearly the Curie itself (a modern SoC) is not going to be a 5V device, so let's examine the schematic for the Arduino 101 and see how they accomplish this.

Level Translation on the Arduino 101. (Source: Arduino.cc)

The board uses three Texas Instruments LSF0108 level translators to accommodate all of the I/O lines (including the analog inputs). This is an interesting part. It's not really a level "shifter", and it's not a buffer. The Curie is still sourcing and sinking current to the pins, but the voltage levels are clamped at 3.3V on the Curie's side of the chip. In this regard it's kind of like a fancy analog switch. The on resistance of each signal path is in the neighborhood of 10 ohms.

The fact that the Curie sources and sinks current to the I/O pins is important to keep in mind. The original specs released for the Arduino 101 claimed a max current per pin of 4 mA. That is quite low, especially when you consider the fact that many Arduino tutorials show circuits that would easily exceed the limit. However, it seems that the maximum current per pin is actually 20 mA, based on a post in the Arduino forum and the now-updated product page. I would still like to see more information on current limits, including any limits for I/O banks and the SoC overall limit.


Digital Output Signals

Enough talk, let's look at some signals. For a first test, I programmed the board to toggle digital pin 12 as fast as possible with the standard digitalWrite() routine. The main loop was free-running with no delays. The Arduino 101 was able to produce a 114kHz square wave with this routine. I measured the rise-time at about 13ns on my scope. We aren't going to set the world on fire with the Arduino digitalWrite routine, but at least we know what we can expect as an upper limit. Knowing these performance limits might be important until we get lower-level access to the I/O.

The output transitions looked very clean with almost no ringing. It's possible the small on resistance of the level translator combined with the capacitance of my scope probe (a low-pass filter) helped in this regard. I'd like to explore the characteristics of the LSF0108 more in the future.

Toggling D12  on the Arduino 101 with a free-running main loop.


Rise time on D12 digital output on the Arduino 101.

For comparison, the free-running loop test on an Arduino Uno generated a square wave with a frequency of about 85.5 kHz. Clearly the processing speed of the Curie will be seen when doing complex mathematical operations, not when twiddling I/O pins.

Toggling D12 on an Arduino Uno with a free-running main loop.


Digital Input Logic Transitions

I applied a DC voltage to pin D7 and varied it up and down while the Arduino 101 reported the logic state in the serial monitor. This was done in order to discover the logic transition levels. Going from high to low, it returned a low state after crossing 1.26V. Going from low to high, however, the transition occurred at 1.55V.


Digital Output Voltage Level Under Load

For the next test, I set pin D7 high and connected it to a variable DC load. I checked the output voltage level at different output currents. With no load, the output voltage was 3.27V. With a 1 mA load, it was 3.18V. At 4 mA, it dropped to 3.04V. Seeing this droop, I didn't proceed to test the rated 20 mA of pin current. The on resistance of the level translator would have made a small contribution to this, but I do suspect that the Curie's output drivers are not extremely robust. I would keep pin currents as low as possible when using the Arduino 101's I/O pins.


Pulse-Width Modulation (PWM)

The Arduino 101 has four PWM outputs (digital pins 3, 5, 6, and 9). This is slightly disappointing, as we have come to expect nearly every pin to be PWM capable on modern 32-bit microcontrollers. I couldn't find documentation on the PWM frequencies used, so let's measure them.

PWM Output on Pin D6.


I found that pins D3 and D9 produced PWM signals with frequencies of 490 Hz. Pins D5 and D6 produced PWM signals with frequencies of 980 Hz. This coincidently matches the PWM frequencies used on the Arduino Uno. I suspect this was only done for compatibility, and presumably an option can be added in the future to change these frequencies. (I wouldn't even be surprised if the RTOS is just toggling these pins at the prescribed frequency and duty cycle to mimic PWM).

Analog Input Linearity

Next I tested the analog inputs. I was curious if the level translators affect the accuracy of the readings. I applied a DC voltage on pin A5, starting at 0V and increasing to 3.3V in 100 mV steps. At each step, I recorded the 10-bit analog-to-digital (ADC) readings reported by the Arduino 101. I then created a graph of the data, which is shown below. As you can see, the results are pretty linear across the entire input range. Spot-checking a few values, I found that there might have been a +20mV bias on the readings at the top end of the scale. However, I would have to tighten up my test setup to verify that. I plan to explore it more in the future.

A graph of analog input voltages versus reported ADC readings.

Conclusion

My initial impressions of the Arduino 101 are very positive. Besides the good test results shown above, the board is very easy to program and work with. The integration with the IDE is seamless, as you would expect from the Arduino eco-system. Uploads are very fast (a couple of seconds) and go the first time. No hitting upload two or three times like on many of the newer 32-bit boards.

There are hundreds of additional tests that could be performed, including benchmarking of real-time code execution. If you would like to see any additional tests in a follow-up post, post them below. Also, please post any comments and corrections.

Thanks for reading!

- Dan W.


MultiNav FeatherWing for Adafruit Feather

0
0
This post will serve as documentation for the MultiNav FeatherWing for Adafruit Feather.

GPS + 9DOF for your Adafruit Feather!

Introduction

The MultiNav FeatherWing is an add-on board for Adafruit Feather. It incorporates a U-Blox NEO-6M GPS module as well as an InvenSense MPU-9250 9 Degrees of Freedom (9DOF) sensor.

The board includes the following additional features:
  • Micro USB connector to connect to the U-Blox GPS. It is accessible using the free U-blox u-center application for configuration and monitoring.
  • u.FL connector for the GPS antenna (supports active antennas, 3.3V or 5V)
  • EEPROM for storing U-Blox configuration between power cycles
  • Power and GPS Pulse-per-second (PPS) LEDs
  • Interrupts broken out for GPS PPS and MPU-9250 interrupt pin

Compatibility

The MultiNav FeatherWing is compatible with Feather M0, 32U4, and HUZZAH. However, the MPU-9250 interrupt pin and GPS PPS interrupt are only accessible with Feather M0 as hardware interrupts.

This FeatherWing may be compatible with other official FeatherWing boards that only use the I2C bus. The MPU-9250 uses I2C with the fixed address 0x68. For FeatherWings that also use GPIO, check the pin usage on the schematic of both FeatherWings to determine compatibility.

For example, the OLED FeatherWing is compatible for simultaneous use with the MultiNav FeatherWing as long as the interrupt solder jumpers are left disconnected.

Shared Files


MultiNav FeatherWing Schematic

MultiNav FeatherWing Board Layout

Assembly

Assembling the MultiNav FeatherWing will require good SMT soldering skills, including having to solder a fine-pitched QFN and castellations.

All part values are shown on the schematic. Most of the passives are 0603. The only exception is L1, which is an 0402 inductor. A handful of parts have specific requirements:
  • GPS Module: U-Blox NEO-6M (Should also be compatible with NEO-7M, but I have not tested this yet)
  • 9DOF: InvenSense MPU-9250 
  • EEPROM: MicroChip 24AA32ASN 8-SOIC or ST M24C32 8-SOIC
  • L1 Inductor: Murata LQG15HS27NJ02D (any substitute must have similar specs)
  • Micro USB: FCI 10103594-0001LF

Datasheets


Usage

The U-Blox GPS on the MultiNav FeatherWing is accessible via UART serial. Before use, you must configure solder jumper JP3 on the underside of the board based on your chosen Feather.

  • For 32U4, bridge Option A and use Software Serial. Pin D10 is Tx, and Pin D11 is Rx.
  • For HUZZAH, bridge Option A and use SoftwareSerial. Pin D10 is Tx, and Pin D12 is Rx.
    • Note: SoftwareSerial for ESP8266 is still largely under development. Here's a good library I used, but it is Receive only.
  • For M0, bridge Option B and use SERCOM1 as shown in the provided example program.

The MPU-9250 is accessible via I2C. It uses the standard SDA and SCL pins, so it is usable on any Feather board. Pull-up resistors for I2C are included in the design of this board.

Two interrupt signals are available when using this board with Feather M0:
  • The interrupt pin from the MPU-9250 goes to pin D5 on M0. If you want to use this interrupt, you must bridge the JP1 solder jumper on the underside of the board. Unfortunately, this pin is not usable with attachInterrupt on the 32U4 and HUZZAH. For HUZZAH, leave JP1 disconnected to prevent boot loading issues.
  • The GPS PPS goes to pin D6 on M0. If you want to use this interrupt, you must bridge the JP2 solder jumper on the underside of the board. Unfortunately, this pin is not usable with attachInterrupt on the 32U4 and HUZZAH. For HUZZAH, leave JP2 disconnected to prevent boot loading issues.

Miscellaneous
  • The PPS LED will blink at the beginning of each UTC second. This signal is generated by the U-Blox GPS module. It's a good way to know when you have GPS signal, as the LED will not blink when signal is lost, or the GPS module is still acquiring satellites. Because this signal is also available as an interrupt on M0, it is a very powerful feature for synchronized and time-critical tasks.
  • An EEPROM is provided on the board for storing U-Blox configuration between power cycles. No backup battery is available on the MultiNav FeatherWing, as the Feather boards have built-in Li-Po battery connections and charging.
  • The USB connector on the MultiNav FeatherWing will also provide power to the Feather (VBUS).
  • The orientations of the various axes on the MPU-9250 are printed in the silk screen of the board.
  • The I2C address of the MPU-9250 is fixed as 0x68.


The MultiNav FeatherWing is released as Open Source Hardware (OSHW) under Creative Commons 2.5 Share-Alike / Attribution license. The same license as Adafruit Feather. Build it, modify it, use it and enjoy!

Thanks for reading!

- Dan W.

Arduino 32-bit Speed Test Shootout!

0
0
I benchmarked some Arduino 32-bit boards, including an Arduino 101, Arduino Due, Arduino Zero clone, and a chipKIT Uno32. I threw an Arduino Uno into the mix for comparison. Here are the results.

Spoiler: The chipKIT Uno32 won. :)

Test Setup

To benchmark these boards, I used an excerpt from the Arduino Show Info program. The sketch includes several speed tests that examine GPIO manipulation speed and raw computational speed. While each of the 32-bit boards tested is very fast, optimization in the IDE also comes into play when measuring performance. Even a 84MHz processor won't make up for poor code structure and inefficient register manipulation in the libraries. So instead of just comparing specs, let's put each board through tests that measure completion time of commonly used program functions.

For the Arduino boards, I used Arduino IDE 1.6.7. For the chipKIT Uno32, I used Mpide 0023.

Benchmarking Program Download: Shared on Github

Please examine this program to see exactly how each  test is structured.


Results

Here are the benchmarking results. Each data point is the time to completion of the test in microseconds. Faster is better. The fastest board in each test is highlighted in green. I also highlighted two concerning results. Two of the tests could not be run on two of the boards due to compilation problems, as indicated.


The results of the speed tests.

Analysis

The Arduino Due and chipKIT Uno32 were the clear winners here. Despite the release of newer Arduino boards, the Due can still hold its own in raw computational speed. There is no doubt that it will be relevant for some time to come with its SAM3X8E microcontroller and large number of GPIO. The dark horse in the test, the chipKIT Uno32, did extremely well. In fact, I have to say it was the winner. It had very fast and consistent GPIO manipulation speed, awesome floating point performance, and it was nearly the equal of the Due in integer math. How much of this is due to the microcontroller versus IDE optimization? I cannot say. But hats off to the creators of that nice little board. It seems to be discontinued, but you can still find it for sale at about $15 cheaper than a Due!

The Arduino 101 did pretty well considering the lower clock speed. It is not a "Due killer" and was never intended to be. While the raw computational speed isn't as fast as I was hoping for, we may see improvements for this board as the IDE is optimized and we get access to the RTOS under the hood. Also, keep in mind that speed is only part of the story. Do any of the other boards have Bluetooth and an accelerometer on board? No. As a potential Arduino Uno successor, the Arduino 101 is a good addition to the lineup.

Speaking of an Arduino Uno successor, the Arduino Zero has been billed as just such a board. I don't have an official Zero, but I did test Sparkfun's take on it, their SAMD21 Dev Board. Sadly, I was a bit disappointed. Sure the SAMD21 chip turned in some good numbers, but I feel that the Arduino Zero is too expensive for what it offers. It is slightly more expensive than a Due with lower performance and less GPIO. With the Arduino 101 out at $25 less in price, where does the Zero fit in? Less expensive Zero-compatible boards might be good alternatives if you want to explore the Cortex M0+ SAMD21 microcontroller.

The Arduino Uno rocked it! Well, ok, it looks pretty slow compared to the other boards. However, remember that it is extremely unfair to pit an 8-bit microcontroller against modern 32-bit devices in speed tests. The Uno still has enough processing power for the majority of hobbyist projects. It is a classic board that will be around for years to come.

There were two concerning results that I highlighted on the table. Analog read performance on the Arduino Zero clone is abysmal! There has to be something wrong in the IDE there. Nearly half a millisecond to read an analog pin is unacceptable. Hopefully it will be fixed in the near future. Also, dstostrf() speed on the Arduino 101 was far too slow. Once again, this has to be due to optimization problems in the IDE. That is not a commonly used function so I doubt many people will notice.

Conclusion

That's it! I hope you found this shootout useful. Download the sketch above and benchmark your own boards and microcontrollers, it's a lot of fun.

If you would like to see a similar shootout with small AVR, PIC and ARM microcontrollers, such as the ATtiny and STM32F030 devices, please post in the comments below. Also post any comments and corrections.

Thanks for reading!

- Dan W.

Wi-Fi and OLED Upgrade for MightyOhm Geiger Counter

0
0
In this post I will show you how to add Wi-Fi connectivity and an OLED screen to the MightyOhm Geiger Counter kit. Lots of fun!

MightyOhm Geiger Counter kit with Wi-Fi and OLED!

Introduction

I assembled my Geiger counter kit from MightyOhm some time ago. It's a very fun kit and the finished counter looks awesome. Oh, that Geiger-Muller tube sitting on that yellow PCB! I've always wanted to modify it somehow and add functionality. Today I realized that an Adafruit Feather sits PERFECTLY where the AAA battery holder normally goes. Doesn't it look like they belong together? I modified the counter, added a Feather HUZZAH ESP8266 with OLED FeatherWing, and whipped up some code. I'm very happy with the end result. Want to do the same to your kit? Let's get on with the tutorial.

Parts List

Here's what you need to complete this mod:


Code for this Project: Shared on Github

Tutorial

NOTE: Please read through this entire tutorial before starting the assembly. There are some important things to be aware of regarding power and program uploading.

First, solder headers to the Feather HUZZAH and OLED FeatherWing. Test those together with Adafruit's example program. If you are unfamiliar with the Adafruit Feather or OLED, I recommend checking out their tutorials. They can be found by clicking on the product links in the parts list above.

Next, assemble your MightyOhm Geiger counter kit. That is a full tutorial by itself. There is just one modification to the instructions. Do not attach the AAA battery holder. We have other plans for that space on the board. You can tack on some wires in its place to test the counter before you continue. If you bought the case, don't put it on yet.

If your kit is already assembled, you need to remove the battery holder. It doesn't require any special tools beyond a soldering iron. First take the case off if you have one. You might also want to remove the tube and put it in a safe place, it is fragile! Remove the nut holding the battery holder, then heat each contact pin one at a time while gently wiggling it back out.

We don't need the battery holder anymore. The Feather will provide 3V to the counter.

Now take a look at my example program. It will display information on the OLED screen, and also publish the radiation count data to your Adafruit IO account over Wi-Fi! You need to modify the program with your Adafruit IO account info, feed names, secret key, and router name/password. See the Adafruit MQTT tutorial for more information about this. Once you have modified the program, upload it to the Feather.

Next, a minimum of three wires need to be tacked onto the OLED FeatherWing. These will connect power and serial from the Feather it sits on to the counter. Look at the Feather HUZZAH's pinout and the pins on the FeatherWing. Find where 3V, Ground, and digital pin #13 would line up. Now cut and strip one end off of each jumper wire, leaving a Female end still attached to each. Solder the wires on the underside of the FeatherWing to the three pads just mentioned. Angle them so they will exit near the JST connector when attached to the Feather. See the next two images for clarification.

If you will want to add a DC jack to this project, also affix a fourth wire to the "USB" pin position. This is where 5V from USB normally goes. I used the JST connection to power the Feather so I did not attach this wire.

The red wire is 3V, the black wire is Ground, and green is pin #13.

Attach the FeatherWing to the Feather HUZZAH, being careful not to crush the wires. Test fit the assembly on the counter board to see where we are headed.

Looking good so far.

Before going any further, you need to know that the USB port will be obstructed once you finish mounting the Feather on the counter. Make sure you are happy with the loaded program before continuing.

Were you wondering why I said to use Female jumper wires instead of normal hookup wire? This is why. I highly recommend testing the program before finalizing assembly to make sure everything works, including your Adafruit IO info. At this point you can connect the Feather to the J6 and J7 headers on the counter. Connect to them as shown below with the wires you attached to the FeatherWing, power up the Feather with a USB cable, and test the assembly. This is also a good time to modify the program as you like.

Header connections on the Geiger counter for testing.

Everything working? Great, let's finish this up. Cut the female ends off of the three wires, strip them, and tin them. Put a piece of double-sided tape on the underside of the Feather HUZZAH and get ready to affix it in place.

Getting ready to attach the Feather assembly to the counter board.

You can use the top cover of the case to make sure the Feather is perfectly positioned. But it fits exactly where the AAA battery holder normally goes. Center it in that black box, and it will be positioned correctly with the case on. Peel off the backing on the double-sided tape and affix the Feather to the counter.

Now flip the board over. We have three connections that need to be made on the back. 3.3V and Ground will attach where the battery holder pins normally go. Also, the serial connection will attach to the Tx pin on J7 that we used earlier for testing.

Wiring on the back of the Geiger counter board. Pretty simple!

Now flip the board over and attach your Li-Po battery or alternate means of powering the Feather. The Feather will power up immediately. Flip the power switch on the counter to ON (yes it still works). After several seconds you should be up and running. The radiation count data will be displayed by default. Press the C button to check Wi-Fi status. If the Feather is not receiving serial data from the counter, it will warn you.

Success!


Large text counts-per-minute display. Get to this mode by pressing the B button.

The program will warn you if it is not receiving serial strings from the counter.

The data is streamed to your Adafruit IO account.


Reassemble the Geiger counter and case. You are done.

Usage

Using the modified Geiger counter with the example program is very easy. As long as you are in range of your Wi-Fi router, the Feather HUZZAH will automatically connect to Adafruit IO and publish data every five seconds. Press the C button on the OLED FeatherWing to see your Wi-Fi status and IP address.

The default view on the screen shows counts-per-second (CPS), counts-per-minute (CPM), and microSieverts per hour (uS/hr). This is the same data that is normally sent by the Geiger counter over serial. You can get back to this view later by pressing Button A.

Button B takes you to a display that only shows CPM in large digits. This is more readable if you want to see the count at a distance.

The Feather HUZZAH echoes the serial string from the counter across USB. This basically adds USB-to-Serial functionality to the counter, which would normally require an FTDI adapter. If you can find a way to squeeze a USB cable into the port when the Feather is mounted, that would be a great option for powering the Feather and doing PC logging. You might be able to use a USB cable with a right angle connector. I didn't have one to test.

Power Options

There are lots of ways to power the modified Geiger counter:
  • USB as just mentioned, IF you can fit a cable into the Feather
  • Li-Po battery through the JST connector on the Feather
  • Fit a DC jack to the project. It would only require adding a fourth wire to feed 5V to the "USB" pin on the Feather as described above. The regulator on the Feather will feed 3.3V to the counter.
  • Provide 3.3V and Ground to the J6 connector on the counter we used for testing. 

Mods to the Mod

You can modify the provided example program to do...anything you want. Adafruit has excellent libraries to help you design fancy display visuals and publish data online. The brains of the Feather HUZZAH is of course an ESP8266, so the options are nearly limitless.

If you just want the OLED display and not Wi-Fi, you can use a Feather M0 or Feather 32U4 instead and modify the example program.

If you want Bluetooth instead of Wi-Fi, use a Feather Bluefruit LE.

That's it! Please post any comments and corrections below. Good luck modifying your MightyOhm Geiger counter kit.

Thanks for reading.

- Dan W.

Glass Envelope Quartz Crystals

0
0
Here are pictures of some interesting glass envelope crystals I received today in the mail. I'm not sure if I should call them "vintage"; they aren't that old based on the date stamps. Very interesting nonetheless. I hope to use them in a project in the future.

5 MHz Glass Envelope Crystal

Better view of the mount in the 5 MHz crystal

Bottom view of the 5 MHz crystal

25 MHz glass envelope crystal

Back side of the 25 MHz crystal

Bonus: 10 MHz PK-171 crystals

- Dan W.





OCXO Upgrade for Racal-Dana 199x Counters

0
0
In this post I will document an OCXO upgrade board I made for the Racal-Dana 199x series of frequency counters.

My Racal-Dana 1992 with the OCXO upgrade installed.

Introduction

I have always been interested in the Racal-Dana 199x series of frequency counters. Though I have plenty of counters already, I was on the lookout for one at a good price to add to my lab. Part of my interest stemmed from the fact that the timebase in the counter is very easy to upgrade, so finding one with the OCXO option was not necessary. Several weeks ago I picked up a model 1992 counter in good shape. It came with the standard XO reference as expected, so I set about designing a small upgrade board.

Gerry Sweeney has some excellent videos on his Youtube channel documenting a very similar project. He created an OCXO upgrade board for his own counter on perf-board that seemed to work well. He also showed how to replace the buttons on the front panel of the counter, which are known to wear out. Thankfully, the buttons on my counter are fully functional (for now).

Check out Gerry's excellent videos on his Racal-Dana 1999 counter:


OCXO Upgrade

Gerry presented a circuit schematic for his upgrade that was very straight forward. For my own board, I used the same LM4140 voltage reference. However, for the control voltage adjustment, I used two resistors and a 20 turn potentiometer in series instead of a single pot. With the values I picked, I have an adjustment range from 0.6V to 3.5V. This works fine for the OCXO I chose, an NDK ENE3311 (datasheet for a similar unit).

The header in the counter where the timebase board mounts is a five pin, 0.1" rectangular male connector with one pin missing. It gives you 5V and Ground and gets 10 MHz back. What could be simpler? I found the mating 5pin connector on Digikey for my board to exactly replicate the original connection.

The 5V rail in my counter is very clean, so I didn't feel it was necessary to do a lot of filtering.

Here's what I came up with:

OCXO Upgrade board schematic.

OCXO side of the upgrade board.

Other side of the upgrade board.

The upgrade mounts exactly like the original timebase, and the trimmer is accessible
through the hole on the rear panel.

Assemble Your Own

If you'd like to assemble one of these boards for your own counter, I have shared the PCB on OSHPark. At current prices, it only costs $16.25 for three copies of the bare board.


Most of the parts can be purchased on Digikey or your favorite distributor. For the OCXO, your best bet is to find a surplus unit on eBay. Purchasing a factory new OCXO will increase the cost of the upgrade by...a lot.

Parts List:
  • OCXO: 10MHz 5V, Square Wave out, 1"x1" standard footprint (example listing on eBay)
  • U1: Texas Instruments LM4140 4.096V VREF SO8 (Digikey listing)
  • R1,R2: 1k ohm, 0603, 50ppm/*C or better preferred
  • R3: 1 ohm, 0603
  • VR1: 5k ohm, 20 turn potentiometer, 50ppm/*C or better preferred
  • C1: 47uF tantalum, 1411, 10V rated minimum
  • C2: 100nF, 0603
  • C3, C4: 1uF, 0603
  • C5: 10nF, 0603
  • Connector: 5 pin 0.1" SIL Horizontal (Digikey listing)

Note: R1, R2, and VR1 values may be adjusted to customize the divider as you like. Using series resistors reduces the adjustment range (giving you finer adjustments) at a degraded temperature coefficient. If you want to use only a potentiometer, place 0 ohm jumpers in the R1 and R2 positions.

A special note about the 5 pin connector: It can be put on backwards! Make sure to test which direction faces down to mate with the pins in the counter before soldering it to the board. If it is installed upside down, the pins will not make solid contact with the header.

Watch the notes on the silkscreen. The OCXO installs on one side, the connector and trimmer install on the opposite side.


TCXO Version?

I was also curious how a TCXO version of this board would perform, so I designed one. Here it is next to the original timebase from the counter.

My own TCXO upgrade board next to the original timebase.


The TCXO performs fairly well. It swings about +/- 30 ppb over a typical warmup cycle. The counter is immediately ready to use from a cold start if I accept that uncertainty. Also, power consumption is low (about 50mW versus 1W for the OCXO). That might be handy if I ran the counter from batteries. (Does anyone actually do that?)

Now the downsides. This TCXO version of the board is actually more expensive than the OCXO version! I had to pop for a really nice $23 VCTCXO to get this level of performance (Connor-Winfield M100V-010.0M). Also, the OCXO I used warms up in less than 3 minutes to an equal if not better level of performance than the TCXO. And of course for long-term stability, and stability over wide temperature ranges, there is no comparison at all. The OCXO wins. Even at the 9 digit resolution of the counter it is noticeable.

So there's really no sense in continuing to explore the TCXO version. Ah well, it is still a nice little board. Maybe I'll find some use for it in the future.

Conclusion

I'm quite happy to have my upgraded Racal-Dana 1992 on the bench. In total, the OCXO upgrade only cost about $26 for a single unit. Though this particular project is wrapped up, I am now working on a similar upgrade for the Fluke/Philips 66xx series of counters.

Good luck if you decide to order PCBs and assemble your own board. Let me know if you need any further details in the comments below. Also, please post any comments or corrections.

Thanks for reading!

- Dan W.


Blog Hits 10k Views + "Quick PCBs"

0
0
Last week this blog hit 10,000 page views! That's very surprising to me, as I haven't posted a huge amount of content to date. When I started this, I only got hits when I posted an article on a mailing list or forum. Now, I get a steady stream of views from followers and internet searches. Thank you to everyone who reads my blog. I do hope that the information I present here is high quality and useful.

Most of my posts are lengthy and intended to document a full project. However, occasionally I make small boards that I need for ham radio activities or general lab use. I think some of these would be useful to share in quick posts, even if they aren't as well documented. To that end, I am going to start posting "Quick PCB" articles that share boards you might find useful on your own bench. They will be small, inexpensive PCBs that you can order on OSHPark. I like being able to share boards for my projects, because I think it helps others re-create the work if they find it interesting.

Here's to 100k views!

- Dan W.

Quick PCB: Pi Attenuator

0
0
This tiny PCB can be used to make a useful Pi attenuator for your bench.

Tiny RF Pi attenuators using surface mount resistors.


Attenuators are useful when you need to reduce a signal's strength by a specific amount. Flatness of the attenuator's response is very important to ensure predictable signal levels across the entire bandwidth of operation. Maintaining the impedance match is also important. You can buy high quality attenuators from manufacturers like Mini-Circuits, but sometimes it's more fun or more expedient to make your own. Luckily you can make very low-cost, low-power attenuators that will have sufficient performance for general use in your workshop.

Alan, W2AEW, has an excellent YouTube video on the theory of Pi attenuators and how to design them. Check out his video. I'll also post a link to an online calculator to aid the design process.



Pi Attenuator Schematic

R1 is in parallel with R2, and R4 is in parallel with R5. This allows you to get odd resistor values needed for some attenuator designs by placing common value resistors in parallel. The back of the board has a white silkscreen box for writing in the amount of attenuation as a reminder.

Order PCBs on OSHPark:


Parts List:

R1 through R5: 0603 or 0805 thin-film SMT resistors
SMA Connectors: Edge-Launch SMA for 1.6mm/0.062" board thickness

Using SMT components for these attenuators allows you to achieve best performance at higher frequencies. These boards have a generally flat response up to about 2GHz. Be cautious of the signal levels you put through these and the power ratings of the small SMT resistors.

With some of these boards, SMA connectors, and a book of SMT passives, you should be able to handle any low-power attenuation needs that arise on the bench.

Thanks for reading.

- Dan W.


Quick PCB: Crystal Ladder Filter

0
0
Here's a little board for making a four pole crystal ladder filter.

Four Pole Crystal Ladder Filter with SMA connectors

This type of filter has a very high Q and narrow bandwidth, allowing you to select a specific frequency from your signal. Because of the narrow bandwidth, selection of the capacitors and tuning of the filter is important to achieve the desired response. You will want to test your filter after designing and assembling it to verify performance.


Theory

Here are some links to cover the design theory. Many more can be found using an internet search.



Schematic of the board


Parts List

Crystals: Standard HC-49 through-hole crystals
C1 through C5: 0603 SMT capacitors
SMA Connectors: Edge-Launch SMA for 1.6mm/0.062" board thickness


If you make some interesting crystal filters with this board let me know!

- Dan W.

HP 5221B Electronic Counter

0
0
It is a snow day here, so let's take a break from projects and look at an old Hewlett-Packard frequency counter. I purchased this 5221B electronic counter last year in San Diego from a military surplus store. It is accurate within its limited resolution, the nixie tubes all work, and overall it is in fine shape.

The display on the counter reading out 3.885 MHz.
Who doesn't love nixie tubes and the smell of vintage HP test gear?


The 5221B sitting on top of a Racal-Dana 1992.
I wonder who put the 5 Megacycles sticker on there. It fit the look of the counter so I left it.


The internal 1 MHz timebase of the counter is well within spec:
less than 1ppm out and I have never trimmed it.


It is hard to do nixie tubes justice in a picture. You just have to see them in
person to appreciate the depth and complexity of each digit in the display.


The form factor of the counter is compact and well executed.
(It is also very hard to photograph.)


I would love to see the "Digital Recorder" that attached to this!


Gold-plated pins on the ICs and point-to-point wiring.
Definitely an instrument from another era.


I'll have to get in there one day and check the Sprague capacitors.
I have had bad luck with those in the past.


One thing that cannot be experienced from these pictures is the unit's smell. As it warms up it fills the room with the scent of test gear from days gone by.

Thanks for reading!

- Dan W.



LoRa FeatherWing Development Breakout

0
0
In this post I will document a LoRa FeatherWing Development Breakout board that I designed for the Adafruit Feather line of microcontroller boards.

LoRa FeatherWing Development Breakout for Adafruit Feather

What is LoRa?


LoRa is an ultra-long range wireless technology that uses sub-GHz ISM bands. It allows the interconnection of small, low-power sensor nodes and Internet of Things (IoT) devices. There are many LoRa transceiver modules on the market from manufacturers such as HopeRF and MicroChip. These modules can be used to connect small, isolated networks of nodes in custom applications. They can also be used to connect nodes to Low-Power Wide Area Networks (LPWANs), such as LoRaWAN.

The choice of module is quite important when designing your project. If you are interested in participating in LoRaWAN, you need to choose a module that is compatible with it. Importantly, significant coding is also necessary to enable the necessary features and functions required by the network. Unless you want to start coding from scratch, you should pick a module with existing library support for whatever development environment you are using.

Check out this great article on The Things Network website that covered various modules and their compatibility. They have documentation on building a LoRa node with an RFM95W module and a Teensy.

HopeRF RFM95/96(W)


The RFM95/96(W) series of modules by HopeRF is a good entry point into LoRa development. There is a substantial amount of documentation, source code, and example projects on the internet to help you get started. Numerous Arduino-compatible libraries have also been developed.

RFM95/96(W) modules can be purchased for as little as $10 from some suppliers. Please read the manufacturer's documentation to become more familiar with them.


As always, low cost comes at a price. The RFM95/96(W) modules interface with a microcontroller over SPI bus plus a few digital I/O lines. If you are interested in LoRaWAN, much of the processing necessary for that is offloaded to the microcontroller and must be implemented in software. By comparison, more complex and expensive modules from other manufacturers do all of the LoRaWAN processing for you, and you merely pass data in and out of the modem.

LoRa Development for Adafruit Feather


I became interested in LoRa technology some weeks ago, and decided to design a small LoRa FeatherWing. I am calling this a "Development Breakout" because it is not entirely ready to use after you solder on the RFM95/96(W) module. My board connects power and the MOSI, MISO, and SCK SPI lines from the Feather to the module. However, there are additional lines that need to be connected based on which library you are using. For maximum flexibility, I decided to break out the DIO, Reset, and SPI chip select pins from the module to a 2x5 0.1" header. This allows you to connect the pins any way you like to the Feather.

The antenna connects via an edge-launch SMA connector. You can select SMA or RP-SMA based on your antennas and requirements.

The example programs I will provide here are compatible with Feather M0, 32U4, and HUZZAH. If you plan to use this board for LoRaWAN, the Feather M0 is required. The LoRaWAN libraries I have seen are quite large, and the 8-bit AVRs do not have enough flash and RAM to support them.

This is only the first board I plan to design. If you want a more polished, ready-to-use board, please stay tuned as the project develops.

Feather HUZZAH ESP8266


I know there will be interest in using this board on the Feather HUZZAH, especially for creating small gateways. I have successfully gotten a Feather HUZZAH to operate in receive mode only, picking up the broadcast strings from a beacon. However, when I attempted to transmit with the Beacon Mode example program, I experienced reset issues on the ESP8266. I'm not sure yet if this is a power issue or an SPI issue, but it will require more experimenting.

Update: Both of the example programs are now compatible with the Feather HUZZAH. A small delay had to be added to the five second wait loop in the Beacon mode program to prevent the ESP8266's watchdog from timing out. Just change your digital pin definitions for the HUZZAH. I found that pins #4, #5, and #2 worked for controlling DIO0, DIO5, and NSS respectively.

Despite compatibility with these simple example programs, the Feather HUZZAH is limited in "clean" I/O pins that can operate as inputs for the DIO lines needed by many LoRaWAN libraries. I am exploring using an 8-bit I/O expander that communicates with the ESP8266 over I2C to enable further LoRa development on HUZZAH.


Shared as Open Source Hardware (OSHW)


LoRa FeatherWing Development Breakout: Order PCBs on OSHPark!



LoRa FeatherWing Development Breakout Schematic

LoRa FeatherWing Development Breakout Board Layout

Assemble Your Own


Here is the information you need if you'd like to order PCBs and make your own LoRa FeatherWings.

Parts List:
  • LoRa Module: HopeRF RFM95W or RFM96W (pick the correct frequency for the ISM bands used in your country)
  • RF Connector: SMA or RP-SMA Edge-Launch for 1.6mm/0.062" board thickness 
  • C1: 47uF 1410 Tantalum SMD capacitor, 10V rated minimum
  • C2: 1uF 0603 Ceramic SMD capacitor
  • C3: 100nF 0603 Ceramic SMD capacitor 
  • LED: 0805, color of your choice
  • R1: 680 ohm 0603, or adjust value to change brightness of LED
  • Headers to connect the FeatherWing to the Feather board 
  • Antenna suitable for the frequency range supported by your RFM module
Note: You can do away with the LED and R1 if you don't want an additional power indicator. Also, you might be tempted to do away with the capacitors C1 and C2 to simplify the bill of materials. The RFM module draws over 100mA during transmissions at the maximum power setting, and ramp-up can be quite quick depending on your configuration. I would recommend the extra bulk capacitance on the board, especially if you are loading the voltage regulator on the Feather with other devices.

Wiring


As noted, this is a development breakout, so you have some additional wiring to do to get the module fully connected to the Feather. I used the following pinout, which is compatible with the example programs I have provided. You can modify it as you like to fit your project or chosen library. The DIO and CS lines from the RFM module only need to go to standard digital I/O pins on the Feather, so you have many options with the 32U4 and M0.

When you try other libraries, you'll probably have to connect more of the DIO pins. Actually, if you look closely in the pictures below, you'll see that I have a different pinout wired up for experimentation. This board is very flexible.


Pinout used in the example programs.


Wiring completed with breadboard jumper wires and a 2x5 0.1" male header.
This allows maximum flexibility to change things, but it's messy.


 Wiring completed with small gauge, solid core wire.
Nice and neat. This is a ready-to-use LoRa beacon!


Example Programs


I debated on which RFM95W Arduino library to use for my example programs. I am aware that many people reading this know a lot about LoRa, have a library in mind, and just need the hardware for the Feather boards. If that's you, awesome. Please enjoy using this board and tell me what you would like to see on future versions. Other people might just need long range wireless connectivity in their project, and don't necessarily want to participate in a LPWAN yet.

I decided to use the RFM95W_Nexus library by Ideetron. This set of code seems to be set up for a specific LoRa development board, but it also has example programs for simple beacon and transceiver nodes operating independently. The portions of code I used don't actually rely on an included library at all, besides SPI. I think this is a great first example program, because it shows you what is actually necessary to drive the RFM module from your microcontroller, without obscuring things into routines. When you get interested in LoRaWAN, the library includes code for that. Additionally, with all of the DIO pins broken out from the RFM module, you can advance to any of the other libraries under development, such as the LMIC library.

The LoRa FeatherWing Beacon Mode program configures the Feather as a beacon that broadcasts a test count every five seconds. This is useful for testing the range of your nodes. The code is very simple, and you will see that modifying the program to send sensor data or anything else you like in the payload is straightforward. Simply load the program, connect a LiPo battery or some other means of power to the Feather, and it will broadcast autonomously.

The LoRa FeatherWing Transceiver Mode example configures the Feather to receive the messages from the Beacon node. There are also functions in there to transmit, so you could modify this into a bridge for long range wireless serial communications. In this example, received messages are echoed across USB Serial, allowing you to verify the receipt of broadcasts from your beacon nodes and test your boards.

Range


The range you can expect from your wireless link is very dependent upon your antennas and environment. Good line-of-sight between the modules is important. Additionally, the frequencies supported by your modules has an impact. Finally, the configuration options you choose for the wireless link will set your maximum data rate, but also affect your range. In the example programs, I set the modules up for 250kHz bandwidth, Spreading Factor 11, and a 4/8 coding rate. These settings favor longer range, with a nominal bit rate of 293bps. Much higher nominal bitrates are possible at the expense of range.

Bandwidth, Spreading Factor, and Coding rate are much too complicated to get into in this article. If you are interested in seeing a separate post explaining those concepts and how they can be use to customize your LoRa FeatherWing project, please let me know in the comments below.

I personally have tested these boards, with the above-mentioned link settings, out to 2.7 kilometers. With a Spreading Factor of 6 (high data rates), I was able to achieve reliable communications out to 500 meters with less than perfect line-of-sight.


Wrap Up


I do hope that you find this FeatherWing design useful. Please let me know if you build one and make a cool project with it, or get it linked into LoRaWAN. Also, please post below any corrections or necessary additions to the information I have presented here. LoRa is very popular in the IoT community, and I look forward to learning from your knowledge and experience in using it.

Thanks for reading!

- Dan W.

10MHz OCXO Teardown (CTS 1960017)

0
0
I recently purchased a case of CTS 1960017 10MHz OCXOs on eBay. They are little 5V units with a sine wave output, and purchased in this quantity, cost $5 a piece. I decided to sacrifice one and open it up to see what's inside. Here are some pictures of the teardown.

Yes, I really meant a "case" of OCXOs. 40 to be exact.

39 of them will be handled with care.

I cut around the bottom of the can, being careful not to go too deep in any spots.
Eventually the can just cracked off in my hand cleanly.

Success.

Lots of passive components and a couple of ICs visible from the top of the board.
I always expect to find more inside these oscillator units than I actually do.

The 14SOIC part is an LM2902 quad opamp.
There is also an SC70-5 part that looks like an output buffer.

This small piece of insulation was wrapped around one side of the crystal.

I cut the pins and flipped the board over.
This side is much more interesting!

The crystal is bonded to the ceramic heater board, and that seems to
be glued to the main board.

Now to put it back together. Hmm...

Thanks for reading!

- Dan W.


ATtiny10 Mini Breakout Board

0
0
Here is a very tiny breakout board for the Atmel ATtiny10. It's so small, you'll lose it. Literally. I lost one in the carpet and I'm hoping to find it before the vacuum does.

ATtiny10 Mini Breakout Board next to a 5mm LED.

A Tiny Breakout for a Tiny Microcontroller


This breakout board is for the ATtiny10 microcontroller. The PCB is 0.25x0.325" and uses 0.050" header pins. The board could actually be made smaller, but I ran into the minimum PCB size limit on OSHPark. Despite the tiny size, I was able to include a 100nF bypass capacitor, power LED, and a user LED on pin PB1. That pin is also the clock pin for the programming interface, so it flashes when the board is being programmed.

This breakout board might be confused for a bug.


How to Program It


The board is so tiny, it's difficult to use and program. It is certainly not breadboard compatible due to the small-pitch headers. To alleviate these problems, I created a small landing pad board for it. This adapts the 0.050" headers to 0.1" headers. Additionally, the landing pad has a 6-pin TPI programming connector. This allows the ATtiny10 to be programmed with an Atmel ICE. You can also program ATtiny10s with an Arduino and a little extra circuitry.

ATtiny10 Mini Breakout Landing Pad

The landing pad is breadboard compatible, and allows you to power,
program, and use the ATtiny10 mini breakout.


What Can I Do With It?


There are many things you could do with a breakout board this small:
  • Use it to design the world's smallest quadcopter and become a billionaire
  • Build an army of cybernetic bats with ATtiny brains
  • Show it off to your friends and demonstrate your fine soldering skills!
  • Leave off the headers and make electronic fireflies
  • Incorporate it into a project's PCB by adding 0.050" male headers on your board. The ATtiny10 may be tiny, but it has 1k of flash, 4 GPIO, a 16-bit counter, PWM, an ADC, and capacitive touch sensing.

Powering it from miniature BPW34 solar cells. This isn't great for LEDs,
but the microcontroller itself is fully functional.


Assemble Your Own


Here's the information you need if you'd like to assemble your own pint-sized ATtiny10 breakouts.

ATtiny10 Mini Breakout Board: Order PCBs on OSHPark! (select the 0.8mm thickness option)
ATtiny10 Mini Breakout Landing Pad: Order PCBs on OSHPark!

Parts List for Breakout
Parts List for Landing Pad

ATtiny10 Mini Breakout Schematic

ATtiny10 Mini Breakout Board Layout

ATtiny10 Mini Breakout Landing Pad Schematic

ATtiny10 Mini Breakout Landing Pad Board Layout

There wasn't enough space for (readable) component identification in the
silk screen, so here's a picture showing where the parts go.

Conclusion


If you assemble your own ATtiny10 Mini Breakouts, let me know! This board is kind of a novelty, but it's fun to play with a fully functional AVR breakout that is so small.

Thanks for reading!

- Dan W.
Viewing all 38 articles
Browse latest View live




Latest Images