The trials and tribulations of making gadgets in Contextual Electronics.
This will be my diary of the progress I make and some of the things I learn and pick up along the way.
The trials and tribulations of making gadgets in Contextual Electronics.
It’s nice to take a break from coding and play with KiCad again. I have the CE Header started with the symbol and footprint done.
As an encore, I could not resist to create the 3d view for pin version and a socket version - of course on an OSH Park board.
Keeping with the suggested positioning of the header relative to the Teensy, I routed slightly differently. I managed to keep the I2C away from the Analogue. I am not sure, though about the way I have have woven the Analogue, if that is also any good.
I also labeled the pins. I have been caught out enough times before when wanting to connect wires for testing, having to go back to the schematic/layout to see where things should go. Though I hope as we use this more often we should get to know this off by heart.
I have received the Teensy board but have decided not to assemble it just yet until I have worked through the sensor board and the which piece will have the sockets and which piece will have the pin headers.
So I have now completed the lay out for the Sensor Board. Keeping in with the suggested form-factor or 1"x1", I did it slightly differently by rotating the 74HC595 so that the majority of the pins to drive the LEDs are on the correct side. This does mean that the LEDs are arranged D1-D8 right to left.
Those (referring to the 3D header models) are awesome, what did you use to make them? Care to share those somewhere?
@ALeggeUp First of all I have to give credit to those who created the original pin headers and connectors. I merely took a copy of those from the KiCad 3dpackages directory and edited them to look like the CE Header. A 3D model as used by the 3D view is a WRL file. The creators of the models have kindly left the source Wings 3D file.
From the KiCad opening page, Preferences->Configure Paths. There is the KISYS3DMOD variable that points to where the 3d models are located (this will be different depending on the platform i.e. OS).
<img src="//ce-forum.s3.amazonaws.com/original/1X/65197a5cb5087242548ce95a8d408e5b065689f5.png" width=70%">
Under Pin_Headers.3dshapes, I copied Pin_Header_Straight_1x10.wings file and edited that with Wings 3D to look like the CE Header. I then saved that as a WRL file and placed that in my own library for the CE Header. I also did the same with a 1x10 connector.
Then in the footprint editor, it is a matter of connecting the 3D model to the part. This is done within the footprint properties dialog
Then it is a matter of using the “Add 3D Shape” button to locate the newly created WRL file to associate with the part.
I had to adjust the orientation a bit alone the Z axis to get the part to look right on the PCB.
I am not really able to give you a blow-by-blow description on using Wings 3D as I use it so seldom, I have to relearn it each time I go into it… but that was the basic steps for creating the 3D model of the connector and associating it with the part.
I finally got back to working on the CE Header and the sensor board. I simply hand-soldered the parts and all went smoothly.
I had to work around the fact that I did not have socket connectors large enough to span the 14 pins on the long side of the teensy. I opted to just directly solder the teensy to the teensy adapter - after what could possibly go wrong?
Even so, I was a bit cautious with just adding the sensor board before suitable testing. I was able to test a couple of the systems on the Sensor board individually. The main one to test was the I²C interface. For that I could use the gear I already have - an USB to I²C adapter from ELV which I have used on another project.
I was pleased to find that I could communicate directly with the temperature sensor without any issues.
I verified the operation of the Light Dependant Resistor (LDR) but I was not convinced on the selection of resistors I chose. I then turned to Falstad/circuit to verify what could be the desired values. Since in referring to some Teensy references, anything above 3.3V (and must be below 5V) will be clipped. So only needed to sense a voltage between 0 and 3.3V. For the LDR I have chosen, I only needed a 10kΩ on the top-side and a 0Ω on the bottom side of the LDR.
The shift register was trickier to check on its own so it was time to connect the Sensor Board to the Teensy.
The Shift register worked fine as did reading the analog value for the LDR to the point I could have a bit of fun and code the LEDs to flicker based on the value from the LDR to create a very rudimentary motion detector.
Ploughing though the Teensy adapter and Sensor board, I did not pick up on Teensy Wire Library. I took it for granted that the pull up resistors would already be applied on the teensy, like they are on the Raspberry Pi for instance. The ELV USB-I²C adapter obviously has the pull-ups. the up-shot was that, to the Teensy, the temperature sensor was invisible. In hindsight, this makes sense. This leaves the Teensyopen to be implemented as a Master or a Slave.
Since I had soldered the Teensy to the adapter, I had space to add the required 4.7kΩ resistors and it all worked fine. I could then implement a thermometer that outputs the temperature in binary through the shift register.
It has bugged me that I could not sort out how to get the I²C decoder working on my Rigol DS1054. The problem stems coming from using the Saleae logic analyser before getting my scope. The assumption was it should all happen automatically like on the Saleae. This video from Nezbrun has now put me straight. I have sample the signal first and then apply the decoder. I did not pick this point up in the user guide of the scope.
The signal captured here is the Teency talking to the DS7505 on the sensor board.
Using this on the scope is rather tedious so the Saleae will be the first thing to use. However, this will now be good for checking problem connections that are not clear on the Saleae.
I have put together a Raspberry Pi adapter board for the lighting project I have been working on. I decided to add a bit more than what I needed and added the CE Header and a 2x20 pin header in parallel. This allows this particular board to be used for testing more than my current project which only needs I2C plus one GPIO. It enables me to also attach CE Header projects as well as plenty of pin-space to attach a scope and logic analyser for verification and testing.
Excellent idea adding the extra pins. It will make it much each to test. I will have to remember to do that for v3.
Timed LED Lighting Controller Update
Its seems ages since the last update. With the new Forum and Open Build Logs, am thinking about moving my personal build-log to here. So here it is…
In the last entry for the Timed LED Lighting System, I had a working model whereby all aspects were working as desired. I have progressed since that update so that the Raspberry-Pi/Django interface is also working (a demonstration will follow). The project is basically ready for install, but I started to have doubts about my chosen enclosure.
According to the AS3000, since system I am working on will be connecting to and switching mains supply, the system becomes an Extra Low Voltage Installation or at best Fixed Appliance.
So down the rabbit hole, I went… Looking for a suitable enclosure that will house, not only this device, but also the 240V LED drivers. I would not deem the cellar, where it will be installed, as a hazardous location so I figured it needs to be at most IP45. Based on the enclosures I have seen, I have decided on using a system comprising of DIN rail (Top Hat EN 50022). Along the way, I have found a neat enclosure for the Raspberry Pi that will sit on the Top Hat rail. From the same group, I found an enclosure that could suite the new system I am thinking of. So it was back to KiCad to re-work the design. I was able to make a couple of enhancements with respect to the positioning and spacing of the indicator LEDs. In the first version, I had an indicator LED each for all sorts of things. I also had them too close together to be able to effectively install any Light-Pipes. As well as fixing the positioning and spacing, I have rationalised LED count from 9 down to 4. So this should save a few mW.
Using a technique I used for the first enclosure, I printed out the PCBs and glued them to cardboard to see if my calculations are working out.
I am happy withe the way things are looking so it is time to send the kicad_pcb files off to OSH Park. With the real boards in my hand, I will know for sure how things are going to fit. I have still to find the enclosure for the entire installation. I am just waiting until I have the working model again with the new setup and then I will know for sure how big of an enclosure I will need.
It is turning out the most challenging part of this electronics project is the mechanical engineering. Turning out a PCB is the least difficult part in comparison to turning out a PCB that will fit in an enclosure and look good.
Signs you’ve lived in Germany for a while: Every project ends up on a DIN rail
In reality, I love DIN rail stuff, it solves a lot of problems and usually has some great features for industrial style projects.
Does that case have the terminal blocks build into the case? If so, how does that work? Link to the case?
Unfortunately the case does not have any terminal blocks. This was another rabbit-hole. I have found something that could suite but will have to order a couple to know for sure. The main criteria is that they have a 5.08mm spacing. It is the height that I am not sure about. I can estimate, there should be a 16mm spacing from the bottom board to the terminal screw hole. I have found an candidate terminal block that is 10mm high.
Oh I didn’t look at the close up of that box, it looked like the bottom and top sections were actually terminal blocks.
I just read your https://smayze.wordpress.com/2017/04/30/from-proof-of-concept-to-prototype/ post and I picked up a couple of the http://www.tag-connect.com/AVRISP cables.
I am looking forward to not have to make room for the height of the pins when I don’t need anything else that tall. Plus, I don’t mind not having to hand solder the pins when the rest of the board is surface mount!
It works really well. I too love not having to solder the pin-headers in place. I have not yet tried out the “No-Legs” version. I do have it though. Laying the connector out is not too bad. I have had to use a 6mil trace to get in between the mounting holes.
What is the total size of that PRG area?
The PRG area as denoted by the silk screen is about 7.5mmx7mm. If the No-Legs version is used, the foot print could be reduced to about 6.5mmx3.5mm
While I am waiting for the new Timed LED Lighting controller DIN rail boards to arrive, I had a bit of fun creating a “test harness” for the system. This allows me to test the system so that everything is rigid and not strewn across the bench. It was actually a good practice run for when it comes time to install the final setup on the wall.
I have put together a short video to demonstrate the system in action - also to showcase the interaction between the Timed LED Control system and a webpage driven by Django and Django Channels.