Steve on camera! Awesome! Great video!
1 Like
A Beginners View on Connectors.
Lately I have come to a point in a couple of projects where I am needing to connect things together as modules. The inspiration for this approach comes from, the CE Header and the concept of modularity with the promise of quick hardware. I ran into a couple of issues with my use of connectors. So I thought to write a quick essay on my findings.
Keeping Things Simple
In the first lot of boards I have created, I kept the connections simple. I would take the Connector symbol and the Pin Header footprint. The implementation was was also simple. Just use simple 2.54mm pin headers in the needed arrangement. i.e. A 2x3 Pin header would easily accept the IDC Female connector of my AVRISP MKII. I just had to be sure to clearly mark pin 1 or the side where the key should face.
I like the idea of prefabricated connectors, making clean connections between boards. But being aware of the added BOM cost - especially during any prototyping or experimental stage, I was more than happy to work only with the Pin Header arrangement.
Now I am working on projects where I would like to connect boards together where on one board, the connector is on the topside and on the other board, the connector is on the bottom side.
I did not realise the issue at first where both sets of pin-headers are modeled on the top-side of the respective boards. It was when I was moving things around so the silkscreens would appear on the correct sides that an issue came to surface. The problem/solution is obvious and I am probably putting myself out on a limb by admitting my oversights but therefore I don’t expect a repeat it.
The schematic shows two connectors that are to appear on different boards. The one on the left will be on the bottom side of its board and the one on the right will be on the top side of its board.
When creating the layout, I made the mistake of modeling both as pin-headers on the layout. The results can be seen in the next lot of images.
It becomes clear that the pins are are not aligned correctly! What is needed is for at least one of these to be modeled as a Socket which are provided in the KiCad library. If I were to keep the pin-header footprint, then both would need to be modeled on the same side of the board to ensure the alignment of the pins.
Conclusion
Keeping things simple and modeling the connectors on the same side of the respective boards will work but caution is needed when wanting to model the same connector on different sides of the board. In this case either a socket or pin compatible counterpart footprint needs to be created.
1 Like
A First Repair Job
Since starting with Contextual Electronics, I have ventured into areas I thought I would never see. Soldering SMD components was the first big milestone. Today I am very happy that I could identify a problem part on a bought PIR13 module, replace it and get the PIR 13 back into action.
The PIR 13 is supplied with the schematic and BOM. So I could easily identify the component I thought was affected. The component was a BC848C SOT23 transistor. I just happen to have a SOT23 BC847C on hand. In a lot of respects, the two seem to be compatible. If anything the BC847C specification seems a little more robust than the BC848C. Since the part was used for switching, I figured there should be no problem in giving it a go.
The board has a very compact layout. Having the right tool for the right job helped a lot. I could use my hot air pencil I could easily remove the old transistor. Getting a soldering iron in there was not too big of a problem now that I am a little used to SMD components.
It is such a nice feeling to be able to have the parts on hand to do this job and not have to buy in anything special. Singing the praises of Contextual Electronics, I would have never had dared ( or is it bothered ) to do this before. Though it has to be said - without Contextual Electronics, I would not have been in this pickle in the first place
2 Likes
Awesome Steve. How did you know it was the transistor?
Thanks @mikef, The PIR 13 has three pins +5-24V, GND and an Open Collector Output. I have to admit, I made a wrong connection and after that it stopped reacting to movement. With the help of the schematic, I got a pretty good idea where to start looking. It was really a process of elimination and I managed to start at the right end. I checked the output of the voltage regulator HT7136 and was getting 3.6V. So at least that part seemed to be healthy. So the next logical place to check was the transistor used for the Open Collector. Without the schematic, the job would have been harder to work out where to start.
By “made a wrong connection” you mean the transistor got cooked?
Yes. The connector is not keyed. So the supply 12V was connecting directly to the Open Collector. No physical damage. It just stopped working.
With a few days off, I am able to catch up a bit of my back-log. I have been wanting to try out some displays I discovered at the Nuremberg Embedded World. In order to make use of the display (DOGM081-A), I created a simple adapter board based on their application notes for 3.3V SPI.
The adapter board reduces the 24 pin footprint down to 6 pins which will be much easier to integrate into other projects.
Using a USB to SPI testing tool, I was able to get the display initialised and working with little effort. I am looking forward to playing with these in future projects.
1 Like
Remote Sensing with XBee
Another project I have been chipping away on is a remote sensor for say a solar charger. I don’t actually have the proper solar gear it is intended for, but I do have a rather crude arrangement for a 6V sealed, lead acid battery being tickle charged from a 9V solar panel. This arrangement has worked without any issues for the last four years. I decided to use this for my first “integration test” of the sensor.
The sensor itself, is simply a voltage divider to monitor the battery as well as an on-board temperature sensor. The whole thing connects to a Teensy 3.2 using the CE_Header. The Teensy is powered by the battery under charge via a 5V LDO that I had created a while back to help out with another project.
The test code that I have so far, has the Teensy transmitting the battery voltage and temperature every 5 seconds.
The messages are being received by another XBee attached to a Raspberry Pi -using a small adapter I created for the purpose. On the Raspberry Pi, I have a small Python program to simply print out the message it receives.
This setup is obviously far from optimal in terms of the drain on the battery under charge. At this stage my focus is seeing if these pieces will work together. There is still a lot of work to do along the chain of data creation, transmission and consumption. One of the next steps is to sort out a proper power system for the Teensy and sensor. From the initial tests, the battery readings started at 6.53V and after about 10 minutes dropped to 6.48V and remained there even after one hour (so far). These initial results are encouraging, it needs to be said, we have a sunny day here today and so to better understand the impact of the setup I have for this test case, I should be measuring and comparing the current through the system.
2 Likes
Nice project! Do you know what the range is on those little XBee transmitters? I have a project where I need to sense the water level on a storage tank and transmit it back to the house and these may fit the bill. I really like the design of that solar charger. It looks like it could handle the elements and it’s perfect for these type of applications.
Thanks @jonthomasson, The range of the XBee depends on the model and the antenna it uses. The model shown has the antenna built onto the PCB and is supposed to have a reach of about 30m indoors and 90m outdoors. For today’s test, the sensor unit is on the back terrace and the Raspberry Pi is in the cellar. There is a window nearby so the reach would be about 6m and is working very will for this test.
I did a small write up about working with these for the first time.
The case is IP65 compliant. So it would be suitable for your project. I actually have it as a TODO to change the enclosure for the charger. The problem I have is heat building up when it is left in the full sun in Summer. In that case I usually leave the lid ajar.
1 Like
Very cool, Thank you for the link to those enclosures and the blog post. I may need to end up getting an XBee with an external antenna to get the distance I need. I look forward to seeing how these sensors work out in your project.
A low cost way to excite the electrons in the battery
Teehee!
3 Likes
Getting LEDs to blink in indicate state is fine and does works well when nothing else is available. However, I have been curious to add a display to a project to start to better understand what is required. Not being too adventurous, I decided to start simple. I had mentioned before about some displays I came across at the Nuremberg Embedded World from Electronic Assembly. The project that I want to try them out on is the remote battery checker. The idea being that pressing a button on the checker could show the voltage rather than only going via the Raspberry Pi.
These displays come in many configurations and communication options. The one I picked for a first attempt is the DOGM081-A. I intend to use it in SPI mode. I wrote about this previously and mentioned I had created an adapter that reduces my pin count for attaching the display from 24 pins down to 6.
On the latest version of the battery monitor, I added provision for a one-way SPI connector explicitly to couple with the DOGM081 adapter.
It took a little while to get the display to work. Electrically, everything was fine and I am pleased to say I did not have to add any bodge. The problem came with configuration of SPI. With the help of my USB-SPI tool and Saleae, I could confirm the setup. I then had to translate that configuration to the code. When things were still not working I went through the setup instructions for the display one byte at a time to see if I was missing something. While going through the table of instructions in the datasheet for the display’s driver, I noticed it stated the expected execution time required to complete the instructions. i.e. Clearing the display and returning Home taking just over 1ms each. The rest of the instructions take around 26.3μ seconds - So there was the last piece to the puzzle! I added a delayMicroseconds(50) between each byte sent and suddenly the display started to work!
void initDisplay(){
unsigned int init[9] = {0x31, 0x14, 0x55, 0x6d, 0x74, 0x30, 0x0c, 0x01, 0x06};
SPI.beginTransaction(SPISettings(2000000, MSBFIRST, SPI_MODE3));
// select the chip and set to command mode:
digitalWrite(register_select,LOW);
digitalWrite(display_select,LOW);
for( int i=0; i<9; i++){
SPI.transfer( init[i] );
delayMicroseconds(50);
}
// Deselect the chip and leave in 'Data' Mode:
digitalWrite(display_select,HIGH);
digitalWrite(register_select,HIGH);
SPI.endTransaction();
}
So the pieces are coming together:
- Measuring voltage and temperature
- Being able to send this information to a Raspberry Pi
- Displaying the information locally
There is still a lot more to sort out with this project. The code is very much test code and I need to get some more formal conversations happening between the Raspberry Pi and the sensor. The other issue is the power consumption. According to my Lab supply, the whole device is drawing around 80mA. I am hopeful I can reduce this a bit. i.e. Using the display on demand, optimising the voltage sensing and even better utilise sleep modes on the micro.
2 Likes
Looks good! Nice detective work with the timing on the display driver. That would have had me stumped for a while.
1 Like
Nice work Steve, the timing would have stopped me.
1 Like
Thanks guys. The motivating force was that the display worked fine with the USB-SPI tool and I could see the messages being transmitted seemingly correctly from my board. I was doubting it was the setup string as this was the same being transmitted by the USB-SPI tool.
The lesson I have learned on this one is not to take it for granted the information presented on the logic analyser. All the timing information is all laid out. I was focusing on the bytes begin sent. The screen shots show what was staring me in the face. The USB-SPI tool places a 0.7731ms delay between the bytes sent. Without any delay, the Teensy will have a 0.6667μs gap - and the data sheet is indicating a 26.3μs execution time. No wonder it was having trouble.
Boy have I learned that one the hard way many times in the past. Almost out of habit now, I swap over to a scope pretty quickly to “sanity check” my setup.
@ChrisGammell, I really need more practice with the scope to know how to read it properly. I did try using the scope first, since I have worked out how to get the decoding working on the scope. But it was not telling me what I was wanting to see. Where as the Saleae will annotate the actual trace (not that I was taking any notice at first ;)).
Thinking about it again, I was probably missing something on the scope setup. The additional issue I had, that the logic analyser quickly pointed out, was that my code was assuming Mode0 SPI configuration. The USB-SPI seems to be using Mode3.
Still thinking about the remote battery checker, I have started looking to how this could be powered more efficiently. A reasonable starting point seemed to be based on the Power Swap project in CE. My requirements have different specs i.e 1 cell supplying 5V for my current setup. I figured a reasonable place to start was the TI Webench®. Restricting the search down to only one manufacturer was not such a big deal for me at the moment. I just wanted to try this out to understand better what I will get.
From my input parameters - input of around 3V7 and out put of 5V, a set of candidate designs were shown and I picked a design containing the LM2621.
The provided design was not far off the one specified in the data sheet for the typical application. Just the values for a couple of the feedback parts differed. I have read through the datasheet, but it is not clear to me why these parts would differ and what effect they will have on the final implementation. To this end, I will see if I can allow for both variations of parts on the board. In the design, I have broken out some pin-headers to simplify the attaching of an amp and voltage meters.
Conveniently the datasheet contains a suggested layout, which I have tried to follow. Since I am trying to follow the suggested design, this means large areas of copper zones and also, for the first time, the usage of 0402 parts. I have already ordered the stencils. I think I will be doing this one in oven.
