Cool, thanks! I didn’t realize that sort of model was available through digikey.
Trace Parts Online also has a lot of parts. Not sure how many electrical parts they would have, but they do have a lot of connectors/plates/etc.
Digikey is certainly adding more, which is a great idea. Used them while I was doing a simple rebuild/redesign of a board for a customer and it was nice to check the connector fit to a front panel with step exports
I was able to make a little bit of progress on the SX1238 rf transceiver module recently. I have to admit that I was nervous just thinking about hand soldering these boards, given the close proximity of several small 0402 components and the large ground pad under the transceiver chip. For this reason I thought it would be a good time to try out a solder paste stencil. After seeing how well @Steve_Mayze’s boost regulator project turned out I decided to give oshstencils a test run.
Since I hadn’t done a stencil before, there was a bit of a learning curve. I found some resources that helped me get started. The first was this page from rheingold heavy which introduced some of the parameters needed, such as the solder paste clearance, to get the gerber files ready to send to oshstencil. The second resource was from this forum post by @ChrisGammell on the kicad.info forums. Specifically this picture helped me visualize how the pad mask parameters in Kicad worked :
The first step for me was to determine which pads on the PCB required a stencil. At first I was thinking about just including all the SMD components. But after giving it some more thought I opted to leave out the SMA connector and shield, since I wanted to be able to test the circuit out first before sealing it in its metal house. And the SMA connector would require some hand soldering to get a good connection.
Now that I knew which SMD pads I wanted to exclude from the stencil, I took those pads out of the stencil by unchecking the F. Paste layer (the front solder paste layer) from the Technical Layers area of the Footprint Editor. This disassociates the pad from the front solder paste layer. It looks like F. Paste is checked by default whenever you create a new SMD pad.
The next thing I learned was that there should be a little bit of clearance between the solder paste and the edge of the pad. This clearance is aptly named “Solder Paste Clearance” and is illustrated on the picture above. This property can be adjusted on a per pad level on the pad properties page, or on a global level. To set the clearance for the entire PCB you navigate to Dimensions -> Pads Mask Clearance from the Pcbnew screen.
On the Pads Mask Clearance screen, there are 2 options for adjusting the solder paste clearance. You can either choose to set the clearance a fixed amount from the edge of the pad, or you can set the clearance to be a ratio based on the size of the pad. I chose to give the clearance a ratio of -5%. After adjusting these properties, the only thing left to do was to generate the gerber files which will be sent to oshstencils. When you go to generate the gerbers, you only need to select the solder paste layer as well as the edge cuts layer, since those are the layers that oshstencils care about.
I was surprised at how quickly I received the stencil back. It seemed like it only took 2-3 days from the time of order to having the stencil in my hand! Besides the stencil, I also ordered a little jig to hold the stencil in position while applying the paste. I found out you can also just use unpopulated PCB’s to fashion your own jig. Here’s a pic of what I came up with:
Once the jig and PCB are in place, you lay the stencil over the PCB until all the pads match up and are visible through the appropriate cutouts of the stencil. Then you tape the stencil down on one side.
From here, my pictures were a little too blurry to share, but I basically followed the same procedure for applying the paste presented in this Sparkfun video. The important thing I learned from all of this was to make sure to clean up the solder paste from the stencil and anything else you want to keep right away. Otherwise it really gets tough to clean up, and it manages to get everywhere!
To reflow the solder paste after I had placed the components I simply used a hot air rework gun. I did have some solder bridges around one of the transceiver chips, but nothing a little drag soldering couldn’t fix. Here’s the finished boards (with a quarter for size reference):
Edit: I noticed that the image for this post went missing. So I uploaded it again.
Just as a fun little aside, I was completely fascinated by the tiny 0402 sized inductors for the RF transceiver. If you look close enough on the board you can kinda see little windings of copper wire. So I thought it would be fun to borrow my daughters microscope and get a closer look at one.
This is blown up about 40x magnification. This one obviously isn’t connected to the board. It’s on its side in this picture. You can see the copper wire bonded to the pads on either end. And some kind of translucent blue goop covering the top. I don’t know, I just thought it was cool.
Edit: I noticed that the image for this post went missing. So I uploaded it again.
The RF transceiver boards passed the initial magic smoke test. I brought the boards up with a current controlled power supply and to my surprise no magic smoke escaped! After that I wired up the SPI bus to an 3.3v Arduino pro mini to see if I could communicate with the transceiver.
I wrote a simple sketch that reads/writes to various registers. The idea here is that if the SPI bus isn’t working, it’s pointless to do any further testing until that can get sorted out. The sketch simply reads the register data to a serial console so I can check it with the default parameters of the datasheet. Here’s the results from the SPI testing:
It looks like the register values match! Cool, so onto transmitter testing next…
Awesome! Are you going to borrow from the Radiohead library? I’ve used that in the past for LoRa stuff. I’m a bit of two minds about it. I feel like having a feel for the registers is very important…but I’m also very lazy
Thanks Chris! There doesn’t seem to be a library currently available that’s tailored specifically for the transceiver that I’m using (the SX1238). Although I have been working on adapting code from this library from low power lab.
The low power lab library is built around the SX1231 transceiver, but it seems to be very similar to the SX1238. The main difference is the SX1238 has an extra LNA on the receive and an extra power amp on the transmit. They do share a lot of the same registers, but most of them have different addresses, and a few registers have been added or removed.
I do agree though, ideally I would use a prebuilt library for something like this. The low power lab library I think will give me a lot of what I need. And the rest will be a bit of a treasure hunt. It does feel like I’m in a bit of uncharted territory, which is both exciting and terrifying at the same time.
Ah, didn’t realize the Radiohead library was for the SX12xx family of parts. Cool, well keep us updated on how it goes! Hopefully it’s well documented on the chip side of things.
That Radiohead library looks like it will come in handy in the future. It seems like it’s a little easier to understand than the one I’ve been working with. Thanks again!
I’ve been working more on writing firmware to test the SX1238 transceiver modules. In my last post the modules had passed the magic smoke and initial communications test. The next step was to see if they could learn to talk to each other.
Although I couldn’t locate any ready made libraries to drive this particular IC, there were a few none the less that helped to guide me in the right direction. Those libraries were the RF69 library by Lowpower Lab, as well as the Radiohead library which @ChrisGammell suggested. These libraries interfaced with a similar model transceiver, the SX1231, which was also designed by Semtech.
One of the features of the SX1238 that intrigued me was that it included not one, but two low noise amplifiers on its receive, as well as two power amplifiers on its transmit. These added amplifiers should not only make it easier to detect weak signals, but should also give the transceiver a theoretical longer range as compared to the SX1231. Here is a view of the block diagram for the SX1238 showing how the internals are laid out.
These added amplifiers, PA2 and LNA1, are turned on/off through three front end control pins, TXEN, RXEN, and MODE. The operation of these pins through the different transmit/receive modes can be seen here:
Interfacing with these pins was of course just a matter of connecting the appropriate pins on the transceiver module to the arduino and then toggling them during the transmit and receive sequence.
To test the transmitter I used a cheap RTL-SDR dongle and the free SDR Sharp software. I just wrote a simple sketch which transmits a packet once a second and looked for the signal to show up somewhere on the FFT plot. It was a thrill to see the signal pop up on the screen for the first time! It was alive!
After this euphoria, I thought setting up the receiver would be the easy part. Boy was I wrong! The firmware for the receiver was setup to simply listen for incoming packets from the transmitter, and then print those packets out to the serial monitor. The excitement was nearly unbearable the first time I uploaded the firmware to the receiver. Expecting to see a rush of packets fill the serial monitor screen, instead there was nothing. Just a blank screen. The roller coaster thrill ride came crashing down and hit with reality.
There was an onslaught of doubt in my mind after this initial test. Maybe there was something wrong with the pcb, or perhaps there was a faulty solder connection somewhere. It was obvious that something was being transmitted since the signals were being picked up by the SDR Sharp software. However, maybe the actual transmission was just garbage.
After taking a break for a bit and getting some air, I decided to dig through the datasheet again and analyze my code a bit more. This digging led me to discover a peculiar register named RegFifoThresh that had as one of its variable names TxStartCondition. TxStartCondition, as its name implies, determines the state at which the transmitter would begin transmitting packets from the FIFO. By default this register was set to only transmit after a specified FIFO threshold had been passed. Since I wanted the transmitter to transmit whenever there was a new packet in the FIFO, I changed this default value to allow the transmitter to transmit whenever the FIFO was not empty. After making this modification and uploading the firmware once again, I started to see a few packets being received and printed out on the monitor. However, the packets weren’t consistent, and the data wasn’t recognizable. But it was progress!
I ended up experimenting for some time with all the various filters and frequency shaping registers. It was fascinating just to make some changes to a few registers and see how it affected the look of the signal in SDR Sharp. I finally cleared the registers pertaining to the frequency deviation of the signal, and reset it to its default parameter. And low and behold, I started receiving packets! I had modified these register values when porting some of the code from the other libraries into my own. It’ll require a bit more experimentation to see what the optimal frequency deviation will for various bit rates, but for now at least I know the design works!
As with all projects, you tend to learn more from the things that don’t work the first time. And this project was no exception. I’d like to think that I have a new appreciation for RF, and just how delicate a balance it can be to get things to behave just right. My oldest daughter and I are in the process of studying for our HAM radio licenses (I currently hold a Novice class) and it was educational for us to see the correlation between these things (frequency deviation, bandwidth, side band) we’re reading about, and viewing them live via the SDR software. It was also reassuring to know that the 5 rules for RF board layout and design that Michael Ossmann gave proved reliable at least for this small project.
Nice write up Jon. You are right about learning when things don’t work. I have made the same experience.
I have been working on some a remote sensor project (write up to follow), but I opted to skip the RF side and use some XBee modules. I wanted to get the end-to-end story happening first before dealing with the RF side properly. It looks like you have simply jumped into the deep end. Well done!
Thank you Steve. There were definitely some moments when I was sure I would drown in the deep end . Without the help of the open source community and RF giants like Michael Ossmann I think this project would have met a tragic end.
This is great, I really like that you were putting your RTL SDR to good use. It acts as a great sanity check for what’s actually getting pumped out of the transceiver. What’s next?
Thanks Chris. Yeah the RTL SDR stuff is pretty cool. It’s almost like an oscilloscope for radio waves. I knew it was transmitting something, just not sure what it was transmitting . Next I’m going to finish up the library and publish it on github so others can hopefully make some use of it. I have a few project ideas, but I’ll have to do some more testing to see what these things are truly capable of first. Now that I know the design works I may end up building one or two more to have some spares.
Continuing from my last post, the SX1238 transceivers were built and tested. Now I wanted to do more field testing to find a suitable application. I have a little less than 2 acres of wooded property so I thought it might be a nice test in range to see if the transceivers could communicate at opposite sides of the property. The transceivers had no trouble communicating at that range, even through buildings. This made me think that these might be perfect for building a small sensor network.
The SX1238 allows for communication for up to 254 devices on one network. I figure that should be plenty for my needs. My plan right now is to build a sensor node PCB that connects into the transceiver. The PCB would have a low power microcontroller for communicating between the transceiver and the sensor. It would also need to be battery powered, or at least have that option since they would most likely be deployed in areas away from power outlets. The sensor nodes would then communicate to a hub (maybe a raspberry pi?) which would act as the brains of the operation and perform whatever tasks needed based on the incoming sensor data.
To save power, the battery operated sensor nodes would most likely be in a sleep or standby state until woken up by either a timer or interrupt from the sensor. At that point they would perform whatever action was needed, transmit that data back to the hub, and then go back to sleep.
For the microcontroller, I’m considering either the STM32L0 or the Microchip ATSAML21 series. Both of these offer ultra low power options that would fit the needs of this project. At this point I’m leaning slightly more towards using the STM32L0 because it seems to have the most community support and since this would be my first venture into ARM, I may need the added support.
For battery power, I’m looking at possibly the CR123A or rechargeable equivalent. They’re approximately half the size of an 18650 and would fit nicely next to the transceiver PCB.
When looking at enclosures, I want something that would obviously stand up to the elements and have the appropriate IP and NEMA ratings. It would be nice to have built in mounting bosses for attaching the PCB. Maybe something like this.
For the antenna, I could either keep the antenna inside the enclosure, or I may end up using something like this IP68 rated SMA coupling and a short length of coax to connect the antenna to the outside world. This would have the benefit of better reception and a smaller possible enclosure. Plus it might just look cool.
To help me stay on course, I’ve come up with a few learning objectives for this project. First I would like to become familiar with programming ARM based microcontrollers. Second, I want to gain understanding in working with and optimizing for low power. Third, to learn to choose and design around an enclosure. And last but not least I would like to learn how to write code for and interface with an embedded Linux system such as the Raspberry Pi. This may be overly ambitious for me, but even if I meet just a few of these goals it would be of great benefit.
I like that case, could definitely see it being mounted on a wall.
I finished designing the first prototype for my home automation node/sensor network. On my last post I had started the research portion of the project. In this post I’ll go over a few design decisions that led to the finished prototype.
At the time I had narrowed down my choice of microcontroller to either the STM32L0 or the Microchip ATSAML21. Both chips are optimized for low power and would be fine for this application. Many factors came into play in deciding which microcontroller would be chosen, such as community support, code samples, availability of cheap dev boards, range of features and ease of use. In the end I decided to go with the STM32L0. The ATSAML21 looks like a great alternative, and I do hope to use it at some point in the future. Something I really like about the STM32 line of microcontrollers is the ability to fine tune the feature set down to one that makes sense for your project. They offer several versions of STM32L0 in the LQFP48 package and each version is pin compatible with the other versions. So for example in this project, I chose the STM32L052 which has integrated USB support, 10 ADC’s and a DAC, but skips features like LCD controllers which are available in the STM32L053 part. This way I can fine tune the microcontroller to fit with the project needs and pay only for what I’m using.
For the power supply I chose the Intersil ISL91127IR buck/boost converter. This particular component had a few things going for it. First it had a low quiescent current of only 30uA, perfect for a low power setup. Second, it shows a nearly 95% efficiency at the anticipated VIN and load current for my project. Third, it has built in short-circuit and over temperature protection. Lastly, it could switch seamlessly between buck/boost mode, with an input voltage range between 1.8 and 5.5 volts. This last feature enables the system to run off a wider assortment of power options, such as lithium primary cells, li-ion rechargeable, and USB. I wanted to have the option of using primary cells when practical because of their low self discharge rate, as well as their ability to withstand greater temperature swings and harsher environments. USB would be a nice feature in areas where power could be supplied via an outlet. For added protection I decided to also include an inline fuse. They are cheap, and a bit of an added insurance policy against the unknown.
To make the board as flexible as possible, and maybe save on future revisions, I decided to add in some extra footprints which may come in handy for future projects. I added in an optional sd card, usb, power switch, vin header, and external oscillators for the STM32. The power switch comes in 2 versions, one which can be mounted with the actuator vertical, and then a horizontal option so it could potentially protrude through the side of the enclosure. I also added some 0 ohm jumpers to add options for switching between different boot and power modes.
Here is the finished schematic:
And the PCB:
The enclosure was something I decided to find early on. I’m not sure if that’s the order this is usually done. My thinking though was that it would be easier to find an enclosure first and then have that set the constraints for my pcb layout. Since I don’t have access to a 3D printer, I’m a bit limited in resources to design a case from scratch. Instead I looked for cases that were pre-built that seemed like they would be good candidates for the project at hand. I also wanted the availability of enclosure’s that could hold up to harsh winter weather. After doing some searching I found some great enclosures on polycase that fit my requirements. I started off with the WP-31F, and then looking through the other case options I realized that the same PCB would actually work for 8 other enclosures. The enclosures are made from either polycarbonate or ABS plastic and come with mounting bosses and a PCB template which can be used in creating your own custom PCB. They also have options for flanged, unflanged, and IP65-IP67 specs. Another nice feature that polycase provides is that they are able to customize the enclosure for you, such as making cutouts for the edge connectors, as well as printing custom designs on the case itself. Here are the “supported enclosures” for this project:
I had some fun when it came to branding. Since I plan on using a Raspberry Pi as the hub that talks to these nodes, I code named this project the Smartie Pi Sensor Node, which when complete, will be part of the Smartie Pi Home Automation System. For the logo I wanted to convey an attachment to the Raspberry Pi, and also a sense of the wireless nature of the project. The final logo is a PCB with pads and castellated edges in the basic shape of the Raspi logo. Then in lieu of the leaves at the top, I have two dish antenna’s transmitting in either direction.
Here are a few 3D glamour shots of the board.
board fully loaded
fitted in the enclosure
Here’s the link to the github repo for those interested. Until next time…
This is an excellent write up. I agree with your approach on selecting the enclosure. Even that can be a challenge with the amount of possibilities of manufacturers and styles. Simple has to be better.
Thanks Steve. Yeah, I had no idea just how many options there were for enclosures. I’ve never really needed one for a project up until now. There are other add on’s available as well, such as vents and cable glands which I’m thinking I may need at some point. In any case it’s been a fun learning experience since it’s opened up a new side of the hobby that I hadn’t really thought much about .
Have had a few other ham radio related projects vying for time recently, but thought I’d give a quick update on the SmartiePi Node. I haven’t ordered the boards yet, but I have had a chance to prototype the firmware using a Nucleo-L073RZ board.
After experimenting with the online MBED development environment to get a blinky example working, I ultimately settled on Atollic True Studio because of its ability to set break points and step through the code as it runs on the device. I’m also using ST’s CubeMX software to setup some boilerplate code for GPIO, clock, and drivers for peripherals.
As a simple first application of the node I want to create a driveway monitor/alert system, to alert me if someone is coming up the driveway. The node would simply transmit a message back to the hub whenever motion was detected. To accomplish this I bought one of these PIR motion sensors from Adafruit. This particular sensor has an output pin that goes high when motion is detected. To interface this pin with the Nucleo board, all that had to be done was hook it into one of the GPIO and configure it to trigger an external interrupt with the CubeMX software. To test out this setup I wrote a simple program which toggled the onboard LED on the Nucleo whenever motion was detected.
After getting the motion sensor working, the next step was to port my SX1238 driver from the Arduino. I used the ST HAL SPI and GPIO drivers to communicate with the SX1238. Most of the code seemed to port fairly easily which was nice. For testing I setup the Nucleo to transmit a packet via the SX1238 module each time motion was detected. On the receive end, I used an Arduino hooked up to another SX1238 module. Here’s the finished prototype.
This should hopefully make testing the PCB’s easier when they arrive.