This week, my targets are the followings:
This week is about electronics and more specificaly abour all kind of outputs:
This week is about ...Topics covered (course) Video recording (course) Video recording (recitation) Students and Labs My files
In the last two weeks, I made a PCB starting from an existing design (the Satshakit). Now, I feel ready to go on my own. I could probably make it work with a single side PCB for this week but I know I will need a double side PCB for my capstone project and I want to give it a try.
As for the Satshakit, I will design around an ATMEGA328P. There is an additionnal challenge this week since the BLE board I want to use does not support 5VDC. This is not just a matter of feeding it with 3.3VDC but also to build an 5V-3.3V interface for every single wire connected to it (check on the bottom left part of the schematic)
And here is the PCB layout
The production process has 4 steps: front-side, holes drilling, perimeter cut. Then flip the board and engrave the back side.
This was my first experiement with double side board and vias. I used small eyelets for the vias. It is required since there is no conductivity whithin the small holes that are drilled in the PCB. The eyelet is like a copper conduit that connects both sides.
I struggled a lot with the alignment. To mill the back side of the PCB, I have to flip it but it has to be very precise to make both sides of the vias to fit exactly on the same place. My first strategy was to drill the mounting holes more deeper (in the MDF support). It could work but it killed my engraving bit. Then I realized I could just flip the target pcb without flipping the entire pcb blank, it is not that difficult to keep it centered.
Having a double side PCB helps to solve the issue I had last week with my connectors. Now, I can solder them on both sides
As per the instructions, I should punch the eyelets and then apply some solder on it, on both sides. But the tool to punch the eyelet is so large that I cannot see them and the result is not always great.
As usualy, a few things went wrong. The pcb shown here is the 5th attempt, all others ended up in the recycle bin. Here is the weekly story:
The SKB369 is a highly integrated Bluetooth 4.2 BLE module, designed for high data rate, short-range wireless communication in the 2.4GHz ISM band. Also, SKB369 support ANT Protocol. The module is based on Nordic nRF52832 radio Transceiver IC, has a 32 bit ARM Cortex-M4F CPU, Flash memory and analog and digital peripherals. The SKB369 provides a low power and ultra-low cost BLE solution for wireless transmission applications. The SKB369 also has a NFC-A tag interface for OOB pairing.
The HW goes as the datasheets says but... the firmware installed on it does not support NFC-A tags and does not support BLE MESH neither. It is possible to re-flash it but it would take more time than I had this week.
Note: all datasheets are within the zip file for this week
This is a development board with a plug and play slot for SBK mini-boards. The biggest advantage is to be able to swap modules without multiple soldering/desoldering operations.
One possible way is to leverage the software installed by the Chinese supplier on the board and their command set.
First, we need to setup the HW and the wiring between the boards. I started with simple elements: a SKB360_EVB with a preloaded SKB369 in the card slot, an Arduino Uno, a logic level converter and two wires between the SKBs and the Arduino The converter is really important since the SKBs do NOT support 5VDC
There is an On/Off switch on the SKB360_EVB. Once turned on, the SKB369 will start advertising as nRF52832 (the part provided by Nordic SemiConductor
Now, let's start the Arduino IDE and try to communicate with the board over an UART link. Here is what we want to implement:
And here are the details
Let's have a look now on what happens on the gateway (Raspi) side now. At startup, the gateway enters in a loop where he is listening and waiting for Fab Buddies to talk to him. As soon as he discovers one of them (based on the fact they advertise themselveswith a name starting with FLMD, the gateway will try to connect back. Here is how it goes then on the Fab Buddy side
And here are the details
For this week, the last part is to demonstrate I can exchange information between Fab Buddies and the Fab Buddy Gateway. As a proof of concept, I will implement a simple heartbeat mechanism. The Fab Buddy will report himself to the gateway on a regular basis. Here is the sequence:
And here are the details
Here are some other sequences I will decribe in the coming weeks and that I want to implement for my capstone project. The first one describes what happens when a RFID tag is swipped. One important point to mention is the fact that the communicaiton is message based, i.e there is no need to wait for the gateway to process a request. The request are put in a queue and processed when it is possible, depending on the laod on the gateway. The response is sent back to the Fab Buddy as part of another message.
This one is the answer provided by the gateway once a card check request is processed
This one is a request sent by the Fab Buddy to charge an expense to a user account
And the last one is what happens when tampering is detected on the Fab Buddy side. I don't know yet how to detect tampering from HW point of view but I will find a way
The source code is here and is fully documented. Here is just a part of it to give an idea of how it looks like
For this demo, my board is on one side and my iPhone on the other side. The nRF Toolbox (from Nordic) runs on the iPhone and my code runs on the ATMEGA328P. At startup, my board will set a unique name (based on SKB369 MAC address) and start advertising
Then I select the advertising device and I press on Connect button on the iPhone. My code continues with a peering confirmation
From there, messages are trasmitted from my code to the iPhone App. Here is the app log
If I kill the iPhone app, my code with resume advertising
Done. Both sides have (statisticaly) unique names (based on ther MAC address)