AUX in Volvo HU-XXXX radio

This post is a description/tutorial on how I managed to hack the stereo (HU-650) in my Volvo V70 (2007) and successfully added my own AUX input. This hack should work with any HU-xxxx unit, "HU" meaning Head Unit (the stereo)

Background

Why, why, why isn't there an AUX input on my car stereo from 2007?
Yes 2007 was before the big era of smartphones, but everyone owned a couple of dirt cheap mp3 players and  iPod was a big thing.

The HU that my car is fitted with has two super retro 8-pin DIN-connections on the back. One of which is for connecting a CD-changer "CD-CHGR" that you could have installed in the boot of the car - but who uses CDs these days?

It didn't take allot of research to find out there is already a product out there that lets you add an AUX to you HU-xxxx. The only drawback is that it sets you back $80 and most of all: It doesn't come with the awesome feeling that you get when you have hacked the stereo yourself.

Research

It wasn't an easy thing finding information on how to hack the HU, but after allot of research I finally found some really good pages that made the hack easy peasy.

This is how it works:

• The source knob on the HU lacks the ability to choose the CD-CHGR until you connect the CD-changer. 
• To trick the HU that you have a connected a CD-CHGR is not as easy as to shorten two of the pins on the DIN-connector, but it has to be done in code via a protocol named MELBUS
• MELBUS is a protocol that utilizes a clock pin and a single bi directional data line to transfer the data between the units and the HU.
• MELBUS uses three lines: Clock, Data and Busy see blue lines on picture below: ("Run" is just 12V from battery)

Picture source

• In the picture above you can also see the Left and Right Audio signals that I tapped into for the AUX-input (Red). 
• Focus on the left DIN-Socket (female) on the picture, that's the back female socket on the HU. 

Hardware

• Arduino Nano (clone) with USB-cable - $2.5
• 8-Pin DIN male plug (pins exactly like the pic above) - $1
• 0.5m network cable - free
• 1m 3.5 mm audio cable - free (who doesn't have a drawer full of them?)

Total cost: ~$3.5

Hacking together some code

Edit 2016-11-04
A guy named Sebastian has modified my code and his version is more stable, and it also works on Mitsubishi HU and supports displaying track numbers! -Here's a link to his code!

Finally some programming! 

I found this awesome write-up that contained almost everything I needed to fool the HU that the Arduino is a CD-CHGR. I will talk you through the process:

1. Set BUSY to low for 1000 ms to make the HU run its initialization routine
1. The HU init routine starts by sending three bytes: 0x07 0x1A 0xEE
2. Then two bytes per optional connection device (~30 of them), the first byte being the predefined ID of the device (ex. CD-CHGR = 0x8E), followed by either an empty byte 0xFF, if the device is not connected, or the answering ID of the device (CD-CHGR = 0xEE)
   
   Example: External CD-CHGR: ID = 0x8E and its return ID is 0xEE
   Example: Internal CD-player: ID = 0x80 and its return ID is 0x86
   See list of predefined addresses and returns on bottom of this site. 
3. I.e. to simulate a connected CD-CHGR we have to: 
1. Trigger the HU init routine
2. Wait until HU is sending out our ID (0x8E)
3. Respond to that by sending back 0xEE 
2. Now the HU has registered that we have a CD-CHGR and it is now available through the source-knob, and will listen to the Left and Right Audio pins on the DIN-plug. 
3. Every time the car ignition is turned on, the HU will automatically run a secondary initialization routine:
1. Starting by sending four bytes: 0x00 0x00 0x1C 0xED 
2. Then two bytes per already registered connection devices from the first init routine, the two bytes follows the same pattern as in the first init routine, first ID, than expecting the same answering byte as before.
3. If the HU won't get an answer from the CD-CHGR, the device will be removed, and we have to set BUSY low again to call the first init-routine.  

That's it for fooling the HU that the CD-CHGR is connected, now it's just a matter of connecting a device to the Left and Right Audio pins plus Ground. I soldered a network cable plus an 3.5 mm Audio cable to the pins of a DIN-plug.

Take care when reading the schematics above, it is the left socket on the picture you are interested in, that's the socket on the back of the HU-unit (female) and will be equal to the back of the DIN-plug.  (as you can see, I put the red cable on the "RUN" to use the 12V to power the arduino, White and yellow are Audio Left and Right)
As a bonus the 12V is only active when the ignition is turned on => no extra load on battery caused by the arduino when car is not used)

The code I wrote (below) is well documented and fairly easy to understand...

I had a hard time getting the function "SendByteToMelbus(uint8_t byteToSend)" to work.
It turned out that the Arduino functions: digitalWrite(MELBUS_DATA, HIGH); and LOW are too slow for this code, (MELBUS runs at 10-12MHz) and CLK had returned to high state before Databit was changed.

To solve this, I had to go back to the old AVR-GCC technique and use
PORTD |= (1<<MELBUS_DATA); and
PORTD &= ~(1<<MELBUS_DATA);
in place of the Arduino functions.

I tried this setup without any form of ground-loop isolation and it works like a charm! Even when the engine is running and my smartphone is charging through the cigaret-socket the sound is crisp and no disturbing noise (alternator suppose to cause ground noise)

I guess one could buy an external Ground Loop Isolator ($5) to be on the safe side....

Power Plug Energy Meter - Now wireless!

This is the second post about my work on the cheap China-style energy meter hack.
My last post covered how I with a logic analyzer successfully (but not in the safest way) sniffed the SPI-transmission on the device and managed to decipher the data. And then how I used an Arduino Nano to do the sniffing for me with an interrupt driven approach. The Arduino  translated the bits and bytes to power and voltage values that it continuously printed on the PC's Serial monitor via an USB-cable.

The next obvious step in this project is to get the energy meter to transmit the data wirelessly. Not only would this mean that I could grab data from several energy meters simultaneously, but it also creates a safe way of debugging the device since my previous setup (which I abandoned after reading some of the comments on Hackaday.com) meant connecting the mains neutral to the computers ground (do not try this at home!!!)

Today's post will cover how I managed to get an Arduino pro mini (3.3V) to sniff the energy meters SPI and transmit the data wirelessly with a nRF24L01+ to an Arduino Nano connected to a computer. The neat thing with this setup is that the Arduino pro mini and the nRF fits perfectly within the casing of the energy meter, and are both driven by the internal power that charges the rechargeable battery that you'll find in the meter.

The total cost of components for each energy meter is:
Energy meter             £7.97
Arduino Mini 3.3 V       £2.58
nRF24L01+                 £0.99   (choose the black + version)
A capacitor + cables   pretty much free, say £1

which comes to a total of £12.54 per unit!

Plus one computer connected node, or a raspberry pi with a nRF24L01 to receive the transmissions from all the energy meters.

Arduino and RF24.h
As mentioned in previous blog-posts I have worked quite allot with the nRF24L01 and AVR's, writing my own libraries and so on. But since this is my first Arduino-project I wanted to learn how to import and use other peoples libraries. Since I am still a newbie in programming, I always have to learn everything from scratch, and nothing ever works as supposed to when I try to follow a tutorial...

I started out by setting up two Arduino Nanos according to this guide and running the example code at the bottom of that page, and as expected - it didn't work. 

Debugging
1. Do I have a working SPI-connection?
I had followed the explanation in the guide i linked to above, on how to install the RF24.h-library and it all seamed to work, I definitely had a working SPI-connection between the Arduino and the nRF since I could print out all the registers, and modifying them also worked...

Took me a while to figure out that I had to download and include the file "printf.h" and call "printf_begin();" to print out data from the nRF to the serial monitor... and why, why, why are they using the "protected" attribute  for many of the functions??? For example get_status is a very useful debug-function and should not be protected!

2. Am I using the correct hardware setup? 
As always I hadn't used the exact components as the instructions said, in my drawer I could only find one 47 uF 24 V  and one 100 uF 16 V capacitors. Well in the guide it sais:
"Connect a .3.3 uF to 10 uF (MicroFarad) capacitor directly on the module from +3.3V to Gnd (Watch + and - !) [Some users say 10 uF or more..]"
And I read 10 uF or more....

Anyways, I thought that this should work, since I have used these capacitors before on the nRF, but not with this library and not with Arduino...

3. I found a working code
Yay, suddenly i found a working code, the "pingpair" example that comes with the NRF.h-library worked with my setup!

4. Why does only Pingpair-code work? 
I started stripping the Pingpair-code of its components, and found that my setup was only working when it got into receiving mode in between every transmission... strange, but keeping in mind that I was using bigger capacitors I figured it had something to do with the capacitors not have time enough to recharge/discharge.

I think this is what happened:
When the Arduino calls the "Write" function, the library runs the "startWrite"-function which powers up the nRF and has a predefined delay of 150 us (wait for the nRF to power up) before it starts transmitting the data.
It turned out that this delay was not enough for my setup, so when I changed this to 1000 us (1 ms), the code worked like a charm even without the receiving functions in between! To do this modification, I opened the RF24.cpp-file (in the arduino Sketchbook libraries folder) with notepad, changed the delay, and saved the file.



Arduino Mini
Just as I managed to get a working Arduino code for the nRF, two Arduino Mini 3.3 V landed in my postbox, awesome timing!

One little problem; the Arduino Mini does not come fitted with an USB to Serial-chip to enable programming over USB.... luckily for me I had an USB to Serial adapter laying around (used for debugging AVR's, as I wrote about in this tutorial-post) that I could use to program the Arduino.

Here's a pic of when I have soldered an nRF to the Arduino and uploading code with the USB to COM adapter via a breadboard (out of sight) so the colored cables does not match the pins...

Off course this didn't work straight away either, I found out that when using this kind of FTDI-adapter you have to press the reset-button on the Arduino Mini just when the Arduino-IDE starts to upload the code to get it working! A better buy would be one of these which comes with an automatic reset-pin ("DTR").

I soldered the nRF to the Arduino, and glued them together with some hot-glue, which was also used to attach the unit to the power meter. Plenty of unoccupied room in the meter behind the LCD, and perfect position for a wireless transmitter!

Here you have the wire diagram: 

I started off by just uploading a simple transmission code on the Arduino mini, that would send a dummy byte once a second to confirm a working setup. I  soldered everything together,  plugged the meter into an outlet and kept my fingers crossed as I watched the Arduino-Serial monitor connected to the receiving unit, and.... noting (of course!)

After several hours of debugging, (I thought I had burnt the nRF by hooking it up directly to the power-meters VCC-pin)  It turned out had I accidentally  uploaded a non-working code to the Arduino Mini.... FAIL!!!

I had cleaned up my working code, and shifted some parts around, it seems like you can't open the writing/reading-pipes on the nRF before you set the datarate/payloadsize/PALevel...

Anyway, the setup I found working is grabbing the power directly from the battery (3.6 V soldered to the underside of the PCB) rather than the VCC-cable (which i think is a bit flaky, and is connected to the RAW-pin on the Arduino, which has a built in 3,3 V regulator. I'm not sure this modification is necessary, but it ensures that the nRF and the Arduino gets 3.3 V. (The pictures above are not connected to RAW, but the Arduino's 3.3 V)

Here's whats transmitted to the computer connected Arduino and printed in the Serial monitor:

I have spent some time looking at ways to store and plot this data in the cloud. One interesting approach is to send the data to a website like http://emoncms.org/ and use there ready to use energy-viewing graphs. With the help of a small python-script I wrote, I can easily send the data from my raspberry pi-server to my account on there website where I have the option of making graphs.

I have also been working in the program called "Processing" which is pretty much the same as Arduino-IDE but for graphing and doing stuff with the data.
I have so far programmed a working graph that shows the data output from up to 6 wireless energy meters, it  also logs the data with timestamp to a csv-file. See the processing-code at the bottom.

Above you see a screenshot of when I have plugged in two energy meters (1 and 2). Nr 1 shows a soldering station which i obviously changed the power on allot during the readings. Nr 2 is a 4-step lamp that i flickered from 3 to 0 to 1 to 2 to 3. as you see i didn't stop at 0 for a very long time, so the graphed mean value stopped at ~10W.

You might wounder why the red and green line (nr 1) sometimes differ? That's because I have the meter to transmit the average=red and the maximum=green power readings on every third power reading. This interval is easily changed by typing 1:1 or 1:4 to change the interval on meter 1 from to 1 or to 4 readings in between transmissions.

I had a hard time figuring out how to transmit this new interval from the computer nrf to the meter, because if I in between every transmission changed the nRF to a receiver, the power consumption would cause the whole meter to stop working.

This time I had to do some serious thinking, and I ended up using the possibility to alter the autoAck-payload. A function that normally sends an "OK" from the receiving nrf back to the transmitting nRF to confirm the transmission. I found out how to alter this value to send something like a "2" instead, or some other integer that would be a new interval. This was exactly what I needed, See the code at the bottom!

Her's the working Arduino code, first for the Energy Meter then for the computer connected receiver-Arduino. At the very bottom you have the processing code:

Here's the code for the receiving Arduino (connected to computer via USB)

And finally the Processing code that can be used to read and write to the computer connected Arduino through its serial connection (over USB)

Power Plug Energy Meter Hack

It has been way to long ago since I tested my capability of hacking things.

Since i am an energy engineer, I have been looking for a cheap and easy way of monitoring my power consumption. 

I know there are other hackers out there that have already worked on this problem, and I have seen dozens of hacks on smart and dumb house-power meters, but only a few that covers power plug energy meters. 

You have the Tweetawatt - awesome, but not my cup of tee (i prefer to write my own software for AVR or Arduino) and still ~55$ each...

And a guy named Connor Wolf has an awesome project where he builds his own and a video where he tares a few standard power plug meters apart. 

I have seen how cheap the China-version of the energy meter is (£7,86), and when i saw the tare-apart video where he takes one apart, I went ahead and ordered two pieces of the EU-type (230V 3,6kW). Of course my intention was to convert them to my own cheaper version of the Tweetawatt.

My final goal is to connect them to the internet either via an nRF24L01+  and my rPi-setup, or with an ESP8266 Wifi adapter (if it will ever arrive in the mail box...)

The future goal is to use an home made Android app to graph the data, i'm not quite there jet, but this tutorial describes how I hacked the power meter and successfully got the voltage, current and power readings to an arduino using interrupts on the CLK. 

The meters showed up last week, and the first thing i did was to open the cover of one of them. 

The guts looked promising since it is very similar to the one in Connor Wolfs video with the 3,6 V battery and the ribbon cable between the two circuit boards. The differences i can see compared to the 110 V version is the big blue capacitor.

The reason I started this project from the first place was because I had seen the ribbon cable labels in the video, so I was very satisfied when I confirmed that the 230 V version also came with the labeled ribbon cable between the power meter and the main processor which sits under the brown circuit board.

The ribbon is labeled: 

VCC, SGND, FREQ, CLK, SDO and SDI as seen here:

I tapped into all of the 7 wires, (7?) yes there are 7 wires, only 6 labeled. closed the case, and plugged it into the wall.

Before i hooked it up to my awesome £6, 8-channel, 24 MHz logic analyzer and started testing it in the logic analysing software, I firs checked all the cables with a multimeter to see that none of them was connected to mains (this video shows that the Kill-a-Watt meter has 110 V on the ribbon cable strangely enough). But the China version was safe on all 7 wires and the five which weren't VCC or GND  got its own channel on the logic analyzer:

###WARNING!!! I'm not an expert in HVAC and there are lots of knowing people that read this article on Hackaday.com and informed me that hooking up the logical analyser like this is an terrible idea! It seems like the energy meters DC-line is not grounded, but instead use Neutral as ground, which can be very different from your computers USB-ground... DO NOT USE MY SETUP, It can be both dangerous and harmful to the computer!

If you want to test the SPI on a non-grounded device they have a lot of suggestions on how this should be done, optical isolation sounds pretty smart (maybe there are even optically isolated USB-hubs you could use?!) I guess I was lucky not to blow up my computer, or my self...

I must admit that this was the first time I have ever attempted to sniff a data communication before, so I had to do a little research. I recognized the CLK as the clock wire in SPI, and guessed that the SDO and SDI was the same as MISO and MOSI but where was the SS (chip select) wire?

My hope was that maybe SPI can work without chip select when there is only one slave that listens, but that would make it heard to know when a transmission starts and end!? how does it sync?

Well, it turns out that I was right, This is the output on a run with nothing connected but the meter:

(click picture for larger version)

Yey, This confirmed my theory and it showed that the FREQ-pin was giving a 50 Hz signal, not at all involved in the SPI communication (nope it's not the SS-line). and that the un-labeled cable was the same as the VCC-labeled pin (high = 3,6V)

This project has improved my analyzing skills allot, and I had to learn how to set up the analyzer to debug the SPI-signal (great SPI-info)

To read this scatter as SPI you need to define the start (where to read the first bit in a byte from)
1. press T1 or hit 1 on keyboard
2. put marker in between SPI-signals (where it's obviously not in the middle of sending a byte)
3-4. Add an Analyzer, choose SPI

Next step is setting up the SPI-analyzer:
1. Press settings
2. zoom in on the first byte, and try and figure out what settings that is used. (see pic under this as well)

Start by "Re-run starting at marker T1" as in picture bellow.

I found that my data is read when CLK is rising "Trailing Edge" and comes in sets of 8 bits (1 byte). 

Note the last MOSI-byte going low, only catched by the trailing edge of clk=>trailing edge

This is how the bits in a byte are interpreted on trailing edge: 

When the CLK goes high, the status on the MOSI and MISO are converted to either 1 or 0. After 8 bits, you have a byte which can be translated to decimal value, as seen above:
MOSI = 1111 1110 => decimal 254
MISO = 0001 0000 => decimal 16

At this time, there was one happy geek in the house!

Decipher the data

Now I had figured out how to sniff the data communication, I still had no idea of what, and in what format the data was sent.

I figured that my best chance of decoding the data would be to sample lots of data and then compare it. So i started sniffing the setup when connecting my soldering station which was perfect since it has the ability to choose different power settings, and for heavy load i used a 1,8 kW water heater.

When comparing the data, it was quite clear that there is not much going on here.The data is sent in chunks of 70 packages at a time, followed by a 47 ms delay. Each package contains 8 bytes, and luckily for me, the first 68 package seems to be the same every time, independent of the wattage reading and they all look like this:

Byte	MOSI	MISO
1	255	0
2	255	0
3	255	0
4	254	0
5	30	0
6	254	16
7	254	3
8	254	193

Sometimes (under high loads) the 16 reads 80, but that's probably because the 7th bit is misread (i haven't found a pattern):
16 = 0001 0000
80 = 0101 0000

But then in the 68th package it always sends:

Byte	MOSI	MISO
1	255	0
2	255	0
3	255	0
4	254	0
5	30	0
6	254	144
7	254	3
8	254	193

Same thing here, 144 sometimes becomes 280

144 = 1101 0000
208 = 1001 0000

Which i think prepares the Master that next 8-byte package will contain important stuff.
This is what comes out in package 69 with different loads:

Byte	SI	SO 0W	SO 8,5W	SO 20W	SO 44,5W	SO 1860W
1	94	0	0	0	0	0
2	128	0	0	0	0	0
3	0	0	0	0	0	0
4	0	0	0	0	0	0
5	24	0	0	0	0	0
6	254	115	116	115	115	111
7	254	238	10	231	236	191
8	254	249	84	123	215	18

Which i figured out to be:
Voltage = 2*(Byte6+Byte7/255) 

Which makes sens because when it goes from Byte6=115 and Byte7>238 to Byte6=116 and Byte7=10 It implies a moderate increas in voltage (231,9V=>232,1V), but under high load, one can expect a voltage drop, and when running at 1,86 kW: Byte6=111 and Byte7=191 (223,5V) seems to be correct!

I guess Byte8 represents a very small fractions of voltage level, so i skip that one.

And the last 8-byte package hopefully gives me some sort of current measurement value so that I can calculate the power!?
Package 70 looks like this with different power loads:

Byte	SI	SO 0W	SO8,5W	SO 20W	SO 44,5W	SO 1860W
1	22	0	0	0	0	0
2	254	0	0	1	1	68
3	254	2	162	7	156	45
4	254	168	114	31	163	243
5	20	0	0	0	0	0
6	254	0	0	0	0	14
7	254	0	17	40	90	137
8	254	2	55	213	248	70

Where I have tried hard to find out what bit 2 to 4 means, please help me with that in the comment field!!!! The meter displays power factor, could it be something with that?

Anyway, I was luckey, it turned out that the last three bits sends the power value like this:
P=(Byte6*255+Byte7+Byte8/255)/2

And to get the current:
P=U*I means I=P/U  and I have all i need!!!!!

And I am one very happy engineer!

A bonus is that changing the setting to view voltage or current, doesn't change the SPI-data.

Arduino MISO sniffer

I can't have a PC next to every power plug energy meter i have hacked so next step was to program a micro controller to do the SPI-sniffing for me.

I have been using AVR's for quite some time now, but this is my first Arduino project, and for testing purposes I'll be using an Arduino Nano, but I have decided to use an 3,3 V Arduino Mini when it's time to solder everything togeather since I have a 3,3 V battery in the meter, and I am planing on transmitting the read data with either an nRF24L01+ to my rPi-setup, or the ESP8266 Wifi adapter (if it will ever arrive...). I wonder if I need a big fat cap to supply the current when sending data like the Tweetawatt!?

Anyways, my plan is to send the data to Gdrive so that i can reach it from an android app or something, but that's future work! If you read this, and now how to log data from ESP8226 to G-drive or Dropbox, I'd appreciate if you gave me some tips!

I first thought of using the built in SPI-function, but learning how to use the "bitbanging" technic on SPI sounded allot more fun! (and I'm not sure the built in SPI would work anyway without SS)

This is the psudo chode I wrote:
1. Connect GND, CLK (green cable) and SO (blue-white) to Arduino (CLKto INT0 and SO to D5) (Arduino 5V from USB for now)
2. Setup interrupt (ISR) on INT0-pin (D2) and make it trigger on rising edge (se ISR-info)
3. When trigger occures: loop as long as CLK is high while logging the time
4. When CLK goes low: check if the delay was between 1-2ms, if so then we are in clk-sync and next clk-rise will be the start of a new byte (this is the delay in between every one of the 70 packages in a transmission)
5. Let CLK-interrupt trigger 40 times to skip the first 5 bytes of the current package
6. Save status on pin 5 (MISO) every time CLK-interrupt triggers to two integers (the next 8*2 times, which will be Byte6 and 7) by using shifting bits method "<<"
7. Let clk trigger 8 more times to finish a complete package and stay in sync
8. check if Byte7!=3, If true: its the 69th package => use byte 6 and 7 to calculate U and proceed with the next step, otherwise (Byte7==3) then: set sync=false and go back to step 3 and wait/look for next package.
9. Let CLK-interrupt trigger 40 more times to skip the first 5 bytes of the 70th package
10. Save byte 6, 7 and 8 in integers by shifting bits each time a new bit is read (8*3 times).
11. Calculate P and then I=P/U
12. Send U,I,P to computer for debug.


And believe it or not, after a good couple of hours of debugging it now works like a charm!

Here is the code that now sends the data to the Arduino-IDE, but is easily changed to an nRF24L01+ and hopefully the ESP8266  as well...

Update!

I now have a working setup where the energy meter is completely wireless with an Arduino mini pro 3,3V and a nRF24L01+ module! =)
Se next post for further information.
/Kalle

Move program between terminals

Finally I have found an easy way of moving a running program from one terminal to another in Linux.

1. Install a neat program called "reptyr"
     $sudo apt-get install reptyr
2. start a never ending program in one terminal
3. start a second terminal and find the PID of the never ending program by running
     $ps -er | grep nRF  
          -where the "nRF" part is part of the never ending program name
          -you might want to make the terminal window broader to see all the text
4. look after the PID that corresponds to the ps-output:
     pi         2801     2800     1   20:57  pts/1       00:00:01 python3   /home/pi/nRF24L01p.py
          -the PID is the number 2801 in the example above.
5. in the second terminal, run:
     $reptyr 2801
and the second terminal will print out 11 rows of text starting with [+] to tell you everything worked, and at the bottom show the out and input of the program.
The first terminal will go on and ask for a new input and act as if nothing has happened.

Another useful thing with the PID is when you want to kill a process. just type $kill 2801 where 2801 is the PID

AndroidPlot in AndroidApp

This will be a simple step by step tutorial in how i managed to get the AndroidPlot up and running in one of my android apps.

The creators of the function has a great tutorial on there website (allot of code is straight from there tutorial), but as always they assumed i had more knowledge than i do to get it working straight away... Since it wasn't enough to follow there steps, and i had to spend allot of time searching the internet for answers i figured i would post a step by step tutorial on how i managed to get it up and running.

1. Download the latest version of the "Core Library" .jar-file from there download page. (the only file you need to download)

2. Save the file into your "libs" folder, and it will automatically import the library under "Android Private Libraries" (if not, left click your project foldet/Properties/Java Build Path/ tab "Libraries" / "Add JARs"...)

3.Create folder res/"xml" which android recognizes as default xml-resources folder.

4. Create two xml-files, first one named "line_point_formatter_1.xml", and secound one whit "2" instead of "1"....

5. paste following code in the first xml-file: (you can put a linebreak in between every setting to get a better overview, but my code-viewer wouldn't let me...)

<?xml version="1.0" encoding="utf-8"?>

And this in the secound file:

<?xml version="1.0" encoding="utf-8"?>

6. Create a new xml file that you name "dimens.xml" and put in the res/values folder. Paste this in the file:

<?xml version="1.0" encoding="utf-8"?>


    
    16dp
    16dp
    10dp
    20dp
    13dp
    13dp
    15dp
    15dp
    20dp

7. Create a layout file in res/layout and name it something like "plotlayout.xml". Paste this code in the file:

8. Create a new .java-file in the src/"com.example.NAMEOFYOURPROJECT" (where most of the java-files are stored) and name the file "Plots.java"

9. Paste this in the file:

package com.androidplot.THENAMEOFYOURAPPLICATION;   //all in small case letters. 

import android.app.Activity;
import android.os.Bundle;
import com.androidplot.xy.*;
import java.util.Arrays;
 
/**
 * A straightforward example of using AndroidPlot to plot some data.
 */
public class Plots extends Activity
{
 
    private XYPlot plot;
 
    @Override
    public void onCreate(Bundle savedInstanceState)
    {
        super.onCreate(savedInstanceState);
 
        setContentView(R.layout.plotlayout); //The name of your plotlayout.xml-file!
 
        // initialize our XYPlot reference:
        plot = (XYPlot) findViewById(R.id.mySimpleXYPlot);
 
        // Create a couple arrays of y-values to plot:
        Number[] series1Numbers = {1, 8, 5, 2, 7, 4};
        Number[] series2Numbers = {4, 6, 3, 8, 2, 10};
 
        // Turn the above arrays into XYSeries':
        XYSeries series1 = new SimpleXYSeries(
                Arrays.asList(series1Numbers),          // SimpleXYSeries takes a List so turn our array into a List
                SimpleXYSeries.ArrayFormat.Y_VALS_ONLY, // Y_VALS_ONLY means use the element index as the x value
                "Series1");                             // Set the display title of the series
 
        // same as above for series 2
        XYSeries series2 = new SimpleXYSeries(Arrays.asList(series2Numbers), SimpleXYSeries.ArrayFormat.Y_VALS_ONLY, "Series2");
 
        // Create a formatter to use for drawing a series using LineAndPointRenderer
        // and configure it from res/xml/config-files:
        LineAndPointFormatter series1Format = new LineAndPointFormatter();
        series1Format.setPointLabelFormatter(new PointLabelFormatter());
        series1Format.configure(getApplicationContext(),
                R.xml.line_point_formatter_1.xml);   //Name of the 1'st xml-config file
 
        // add a new series' to the xyplot:
        plot.addSeries(series1, series1Format);
 
        // same as above:
        LineAndPointFormatter series2Format = new LineAndPointFormatter();
        series2Format.setPointLabelFormatter(new PointLabelFormatter());
        series2Format.configure(getApplicationContext(),
                R.xml.line_point_formatter_2.xml);   //Name of the 2'nd xml-config file
        plot.addSeries(series2, series2Format);
 
        // reduce the number of range labels
        plot.setTicksPerRangeLabel(3);
        plot.getGraphWidget().setDomainLabelOrientation(-45);
 
    }
}

10. Add these lines to the "Manifest file" (found in the root, and named "YOURAPPNAMEManifest.xml")

And put the lines in between these tags:

 and 

11. Now it's time to test the plot. create a button with an onClickListener whit this code in it:

Intent i = new Intent(getApplicationContext(), Plots.class);
startActivityForResult(i, 2);

which will start a new intent which call the Plots-class which in term opens the plotts-layout showing the graph of the numbers.
Now when you know how the file-system works, try next tutorial they have posted, which is a dynamically updated plot over the phones tilt... =)

Autostart Raspberry pi VNC and server

Hi!
Last week i finally configured my Rpi, and had it setup as a server to get 24/7 access to all the gadgets in my apartment. I'm not very familiar with linux, and therefore it is probably a good ide to write down how i managed to do so, for future setups =)

First of all i wanted to get access to the Rpi from my main computer. I had two options, either just by a terminal (SSH), which is probably best for speed, or configure a remote desktop (VNC) to mirror the pi on my main computers screen. Since i'm not to familiar with the linux terminal, i figured i'd start off with the VNC like this...

Setting up remote desktop (VNC) on the Rpi using the program TightVNC according to this guide (skipped the SSH-part in the beginning):

Install the TightVNCServer on the Rpi like this:

$sudo apt-get install tightvncserver #When prompted press 'y'

Then try and start the server by entering: (change the resolution to the screen res where you are going to view the desktop) $vncserver :1 -geometry 1600×900 -depth 16 -pixelformat rgb565
The "1" is an ID, (you can start several different servers)
The program will now prompt for you to enter a password to get access to the remote desktop, set one!

There might be an permission issue, so to make sure that wont happen, do this:  (where "pi" is the username) $sudo chown pi /home/pi/.Xauthority

The VNC-server nr "1" can later be closed by typing: $vncserver –kill :1

Install TightVNC on Windows machine

Now that you have your VNC-server up and running, it is time to install the TightVNC-program on you main computer from there website:

When done, startup the TightVNC-Viewer (not the server), type in the IP-address and the ID that you specified on the pi and press "Connect". A good ide is to configure your router so that the ip of the Rpi never changes...

If the server is running, a prompt for the password will show up, enter it and a window with the Rpi-desktop will popup =)

If you make it full-screen, the way of getting out is by pressing alt+ctrl+shift+F.

Autostart VNC-server when Rpi boots

Next step is to get the server to start automatically when the Rpi starts up. There is no point of having a remote desktop if I every time the rpi starts have to have a keyboard, mouse and a screen attached to it to startup the server...

Create a file named tightvnc in the init.d folder, and open it in nano to edit its content:
$sudo nano /etc/init.d/tightvnc

Enter the following: #!/bin/sh ### BEGIN INIT INFO # Provides: tightvncserver # Required-Start: # Required-Stop: # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: start vnc server # Description: ### END INIT INFO case "$1" in start) su pi -c 'vncserver :1 -geometry 1920x1080 -depth 16 -pixelformat rgb565:' echo "VNC Started" ;; stop) pkill Xtightvnc echo "VNC Terminated" ;; *) echo "Usage: /etc/init.d/tightvnc {start|stop}" exit 1 ;; esac
Press ctrl+x and y to exit and save.

Now we need to set permissions to the file to make it executable: $sudo chmod 755 /etc/init.d/tightvnc

And the last thing we’re going to make is to update the rc.d file (which tracks which initilization scripts are in the /init.d/ folder): $sudo update-rc.d tightvnc defaults

Now it is time to test it: Reboot the Rpi:
$sudo reboot

And try connecting the ThightVNC-program on the main computer.

Autorun other scripts when Rpi boots

To autorun a script that doesn't need permissions when Rpi starts is a little easier. Take my nRF-server for instance:
Create (if not allready created) the folder
$mkdir ~/.config/autostart

Then add a file with the ending ".desktop"  and edit it in nano:
$sudo nano ~/.config/autostart/NRFServer.desktop

Edit the file like this:[Desktop Entry] Version=1.0 Type=Application Terminal=false StartupNotify=true Name=NRF-server Comment=Starts NRF-server Exec=lxterminal --command "sh /home/pi/a.sh" Categories=Application;
Where the importent stuff is the terminal=false (we want to start lxterminal), and the "Exec" that executes the script "sh /home/pi/a.sh" in the lxterminal, which is the script that starts the server...
Exit nano with ctrl+x and save (press y)

Now to make the .desktopfile executable:
$sudo chmod +x ~/.config/autostart/NRFServer.desktop

Reboot the Rpi, and you can see that the lxterminal has started the NRF-server in an open terminal!

Raspberry pi: nRF24L01 and TCP

This time I will describe how I got a Raspberry pi (Wheezy) to work as a Python server that controls a RF-transmitter (nRF24L01). The server takes commands either from a TCP connection (internet) or via the keyboard, and broadcasts the data through the RF-transmitter to the receivers i have set up in my home automation system. See my other posts covering how to use the nRF with an AVR, and the construction of a  multi-functional remote control.

        

Why use a Raspberry pi when i already have a working TCP-server on my PC?

Easy answered:

• I do not like to have my PC up and running 24-7 due to the facts that it's noisy (stationed in my bedroom)
• The RPi takes much less energy (runs on a 1000mA cellphone charger)
• I don't need any other parts other than a RPi, a nRF24L01(+) and cables, since the RPi has a 3,3V power supply!

Setting up SPI on RPi

First of all, you must have a working copy of raspbian, I use Wheezy (made a small tutorial in how to set it up). The RPi has a built in hardware SPI, which we first has to get up and running according to this guide, and here is how i did it:

Start a terminal like the LXTerminal and follow these commands:
$sudo apt-get install git $sudo wget http://goo.gl/1BOfJ -O /usr/bin/rpi-update #(the O is not zero but the letter) $sudo chmod +x /usr/bin/rpi-update $sudo rpi-update $sudo nano /etc/modprobe.d/raspi-blacklist.conf #add '#' in front of 'blacklist spi-bcm2708' (to comment it out) ctr+o (save) then ctrl+x (exit) $ sudo shutdown -h now #(remove power cable and readd it to restart) $cd /dev $ls #(check that ”spidev0.0 and 0.1 is in the list as in picture underneath)


To check if the SPI is working (optional) you can connect the mosi-pin to the miso-pin (GPIO10 and 9, see picture), and run the commands in a terminal:

$wget http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/spi/spidev_test.c spidev_test.c $ nano spidev_test.c #(scroll down and change ”*devic = ”/dev/spidev1.1”; to ”/dev/spidev0.0" , press ctrl+o (save) ctrl+x (exit) $gcc spidev_test.c #(creates a runnable file) $sudo ./a.out #(runns the file) #The output should now look like this:

Quick2Wire

Quick2Wire is a tool that makes it possible to control the GPIO and the SPI via python. We need to install quick2wire, download the quick2wire python plugin (API) and gain root access to the spi.
Start by downloading the plugin from there website. Extract the zip-file by right clicking and unzip. Now open a terminal window and change directory so that you are in the extracted folder called "quick2wire-gpio-admin-master" then enter the following commands:

$ make $ sudo make install $ sudo adduser $USER gpio

Now log out from the RPi and back in again. The power button at the bottom right quorner has the option to log out. Log back in by typing your username "pi"/enter, then your code "raspberry"/enter...

To gain root access for the SPI so that you dont have to use the "sudo" command in front of every bit of code, I followed this guide, which tells you to do this:

$ sudo groupadd -f --system spi $ sudo adduser pi spi $ cd /etc/udev/rules.d2/ $ sudo nano 90-spi.rules $ SUBSYSTEM=="spidev", GROUP="spi" $ #press ctrl+o (save), Enter, ctrl+x (exit) $ sudo shutdown -h now
Finnish by remove and reattach the power cable to restart.

Python 3

Now it's time to install python3 which is needed to run the code. Open a terminal and run these commands:
$ sudo apt-get install python3

Now to use quick2wire with python, you need the python API which can be downloaded from this site. Download it, and unpack it to a location on you SD-card (no installation required!)

Setting up the hardware

The setup is very straight forward. Connect the wires like this (see red circles in the picture):
RPi GPIO9     (Pin 21)    to RF  ( MISO )
RPi GPIO10   (Pin 19)    to RF  ( MOSI )
RPi GPIO11   (Pin 23)    to RF  ( SCK )
RPi GPIO8     (Pin 24)    to RF  ( CSN )
RPi GPIO18   (Pin 12)    to RF  ( CE )
RPI 3.3V        (Pin 17)    to RF  ( VCC/3.3V )
RPi Gnd         (Pin 25)    to RF  (GND)
(IRQ-pin on nRF is not used in this example)

nRF24L02+ (top view)

nRF24L01 (only one of each VCC and GND-pin has to be connected!)

I think the CE-pin should work on a different pin (it would be convenient to put it on GPIO25) since it doesn't have anything to do with the SPI, but I haven't tried that yet...

The python programs

I got the basic nrf python code from this program (plus a lot of help with the steps above) from Jussi Kinnunen, all creds to him!
Download  my version of the program, as well as my TCP-server program. which is well commented to make it easy to understand. You see the codes below:

nRF24L01p.py
#!/usr/bin/env python3 from quick2wire.spi import * from quick2wire.gpio import Pin from quick2wire.gpio import In,Out,pi_header_1 import time #import TCP_Server #Uncomment this if you are running a TCP-server!! (this and one more line in the while-loop at the bottom!) PAYLOAD_SIZE = 3 SMALL_PAUSE = 0.05 LONG_PAUSE=0.5 #Define settings variables for nRF: SET_ACK = 0x01 #Auto ack on (EN_AA) SET_ACK_RETR = 0x2F #15 retries, 750us paus in between in auto ack (SETUP_RETR) SET_DATAPIPE = 0x01 #Datapipe 0 is used (EN_RXADDR) SET_ADR_WIDTH = 0x03 #5 byte address (SETUP_AW) SET_FREQ = 0x01 #2,401GHz (RF_CH) SET_SETUP = 0x07 #1Mbps, -0dB, (250kbps = 0x27) (RF_SETUP) ADDRESS = 0x12 SET_RX_ADDR_P0 = [ADDRESS,ADDRESS,ADDRESS,ADDRESS,ADDRESS] #Receiver address( RX_ADDR_P0) SET_TX_ADDR = [ADDRESS,ADDRESS,ADDRESS,ADDRESS,ADDRESS] #Transmitter address (TX_ADDR) SET_PAYLOAD_S = 0x03 #3byte payload size (32byte = 0x20)(RX_PW_P0) SET_CONFIG = 0x1E #1=mask_MAX_RT (IRQ-vector), E=transmitter, F= Receiver (CONFIG) #nRF registers: CONFIG = 0x00 EN_AA = 0x01 EN_RXADDR = 0x02 SETUP_AW = 0x03 SETUP_RETR = 0x04 RF_CH = 0x05 RF_SETUP = 0x06 STATUS = 0x07 OBSERVE_TX = 0x08 CD = 0x09 RX_ADDR_P0 = 0x0A RX_ADDR_P1 = 0x0B RX_ADDR_P2 = 0x0C RX_ADDR_P3 = 0x0D RX_ADDR_P4 = 0x0E RX_ADDR_P5 = 0x0F TX_ADDR = 0x10 RX_PW_P0 = 0x11 RX_PW_P1 = 0x12 RX_PW_P2 = 0x13 RX_PW_P3 = 0x14 RX_PW_P4 = 0x15 RX_PW_P5 = 0x16 FIFO_STATUS = 0x17 READ_REG = 0x00 WRITE_REG = 0x20 RESET_STATUS = 0x70 WR_TX_PLOAD = 0xA0 RD_RX_PLOAD = 0x61 FLUSH_TX = 0xE1 FLUSH_RX = 0xE2 NOP = 0xFF class NRF24L01P: def __init__(self): """__init__ function is allways run first, when the class is called!""" self.nrf24 = SPIDevice(0, 0) #Define SPI-unit (used in doOperation) self.radio_pin = pi_header_1.pin(12, direction=Out) #"CE" on nRF, output def doOperation(self,operation): """Do one SPI operation""" time.sleep(SMALL_PAUSE) #Make sure the nrf is ready toReturn = self.nrf24.transaction(operation) #Sends bytes in "operation" to nRF (first what register, than the bytes) return toReturn #Return bytes received from nRF def ReadPrintReg(self, Register, name, numbers): """Function that grabs "numbers" of bytes from the registry "Register" in the nRF  and writes them out in terminal as "name....[0xAA,0xBB,0xCC]" """ bytes = [READ_REG|Register] #First byte in "bytes" will tell the nRF what register to read from for x in range(0, numbers): #Add "numbers" amount of dummy-bytes to "bytes" to send to nRF bytes.append(NOP) #For each dummy byte sent to nRF later, a return byte will be collected ret = self.doOperation(duplex(bytes)) #Do the SPI operations (returns a byte-array with the bytes collected) #print(ret[0]) #debug #print(hex(ord(ret[0]))) #debug #print(bin(ord(ret[0]))) #debug Res = [hex(z)[2:] for z in ret[0]] #convert byte-array to string list #print(Res) #debug while len(name)<15: #Fill the name with "." so it allways becomes 15 char long (e.g. "STATUS.........") name = name + "." #Print out the register and bytes like this: "STATUS.........[0x0E]" print("{}".format(name), end='') #First print the name, and stay on same line (end='') for x in range(1, numbers+1): #Then print out every collected byte if len(Res[x]) == 1: #if byte started with "0" (ex. "0E") the "0" is gone from previous process => (len == 1) Res[x]= "0" + Res[x] #Readd the "0" if thats the case print("[0x{}]".format(Res[x].upper()), end='') #Print next byte after previous without new line print("") #Finnish with an empty print to contiune on new line and flush the print (no end='') return Res[1].upper() #Returns the first byte (not the zeroth which is allways STATUS) def receiveData(self): """Receive one or None messages from module""" #Reset Status registry bytes = [WRITE_REG|STATUS] #first byte to send tells nRF tat STATUS register is to be Written to bytes.append(RESET_STATUS) #add the byte that will be written to thr nRF (in this case the Reset command) self.doOperation(writing(bytes)) #execute the SPI command to send "bytes" to the nRF try: self.radio_pin.open() #Open the "CE" GPIO pin for access self.radio_pin.value=1 #Set the "CE" pin high (3,3V or 5V) to start listening for data time.sleep(LONG_PAUSE) #Listen 0,5s for incomming data self.radio_pin.value=0 #Ground the "CE" pin again, to stop listening self.radio_pin.close() #Close the CE-pin except(KeyboardInterrupt, SystemExit): #If ctrl+c breaks operation or system shutdown try: self.radio_pin.close() #First close the CE-pin, so that it can be opened again without error! print("\n\ngpio-pin closed!\n") except: pass raise #continue to break or shutdown! ret = self.doOperation(duplex([STATUS])) #Get the status register as byte-array Res = [hex(z)[2:] for z in ret[0]] #convert byte-array to string list Res = Res[0].upper() #Convert the interesting byte to one string, upper case (e.g. "4E") if len(Res) == 1: #if string started with "0" (ex. "0E") the "0" is gone from previous process => (len == 1) Res= "0" + Res #Readd the "0" if thats the case if(Res != "0E"): #If something is flagged in the STATUS-register self.ReadPrintReg(STATUS,"STATUS",1) #Print out the status-register if Res == "4E": #If data is received correctly self.ReadPrintReg(RD_RX_PLOAD,"Received",PAYLOAD_SIZE) #Print out the received bytes else: print(".", end='') #Print out dots to show we are still listening! sys.stdout.flush() #the end='' only puts it in the buffer! def sendData(self,toSend): """Sends x bytes of data""" #Reset Status registry for next transmission bytes = [WRITE_REG|STATUS] #first byte to send tells nRF tat STATUS register is to be Written to bytes.append(RESET_STATUS) #add the byte that will be written to thr nRF (in this case the Reset command) self.doOperation(writing(bytes)) #execute the SPI command to send "bytes" to the nRF #Flush RX Buffer self.doOperation(writing([FLUSH_TX])) #This one is special because it doesn't need any more than one byte SPI-command. #This is because the FLUSH_TX is located on the top level on the nRF, same as the "WRITE_REG" #register or the "READ_REG". (See datasheet Tabel 8) #Print out the STATUS registry before transmission self.ReadPrintReg(STATUS,"STATUS before",1) #Print out the transmitting bytes with quotations ("chr(34)"), Payload cannot be read from the nRF! print("Transmitting...[{}{}{},{}{}{},{}{}{}]".format(chr(34), chr(toSend[0]),chr(34),chr(34), chr(toSend[1]), chr(34), chr(34),chr(toSend[2]),chr(34))) #This checks if the first byte to send is a "9", and if so, changes the address on the nRF. a = "".join([chr(x) for x in toSend]) #print(a) if(a=="009" or a=="019"): self.changeAddress(0x13) #Calls function located further down elif(a=="002" or a=="003" or a=="004"):# self.changeAddress(0x14) #Print out the address one more time, to make sure it is sent to the right receiver. self.ReadPrintReg(RX_ADDR_P0,"To",5) #write bytes to send into tx buffer bytes = [WR_TX_PLOAD] #This one is simular to FLUSH_TX because it is located on the same top level in the nRF, #Even though we want to write to it, we cannot add the "WERITE_REG" command to it! bytes.extend(toSend) #Because we now want to add a byte array to it, we use the "extend(" command instead of "append(" self.doOperation(writing(bytes)) #Write payload to nRF with SPI try: self.radio_pin.open() #Open the "CE" GPIO pin for access self.radio_pin.value=1 #Set the "CE" pin high (3,3V or 5V) to start transmission time.sleep(0.001) #Send for 0,5s to make sure it has time to send it all self.radio_pin.value=0 #Ground the CE pin again, to stop transmission self.radio_pin.close() #Close the CE-pin except(KeyboardInterrupt, SystemExit): #If ctrl+c breaks operation or system shutdown try: self.radio_pin.close() #First close the CE-pin, so that it can be opened again without error! print("\n\ngpio-pin closed!\n") except: pass raise #continue to break or shutdown! self.ReadPrintReg(STATUS,"STATUS after",1) #Read STATUS register that hopefully tells you a successful transmission has occured (0x2E) print("") if(a=="009" or a=="019" or a=="002" or a=="003" or a=="004"): #If you changed address above, change it back to normal self.changeAddress(0x12) #Change back address! def changeAddress(self,Addr): """Function to change address on both RX and """ bytes = [WRITE_REG|RX_ADDR_P0] bytes.extend([Addr,Addr,Addr,Addr,Addr]) self.doOperation(writing(bytes)) bytes = [WRITE_REG|TX_ADDR] bytes.extend([Addr,Addr,Addr,Addr,Addr]) self.doOperation(writing(bytes)) def setupRadio(self): """Function that sets the basic settings in the nRF""" #Setup EN_AA bytes = [WRITE_REG|EN_AA] bytes.append(SET_ACK) self.doOperation(writing(bytes)) #Setup ACK RETRIES bytes = [WRITE_REG|SETUP_RETR] bytes.append(SET_ACK_RETR) self.doOperation(writing(bytes)) #Setup Datapipe bytes = [WRITE_REG|EN_RXADDR] bytes.append(SET_DATAPIPE) self.doOperation(writing(bytes)) #Setup Address width bytes = [WRITE_REG|SETUP_AW] bytes.append(SET_ADR_WIDTH) self.doOperation(writing(bytes)) #Setup Freq bytes = [WRITE_REG|RF_CH] bytes.append(SET_FREQ) self.doOperation(writing(bytes)) #Setup Data speed and power bytes = [WRITE_REG|RF_SETUP] bytes.append(SET_SETUP) self.doOperation(writing(bytes)) #Setup Receive Address bytes = [WRITE_REG|RX_ADDR_P0] bytes.extend(SET_RX_ADDR_P0) #"extend" adds a list to a list, "append" adds one obect to a list self.doOperation(writing(bytes)) #Setup Transmitter Address bytes = [WRITE_REG|TX_ADDR] bytes.extend(SET_TX_ADDR) self.doOperation(writing(bytes)) #Setup Payload size bytes = [WRITE_REG|RX_PW_P0] bytes.append(SET_PAYLOAD_S) self.doOperation(writing(bytes)) #Setup CONFIG registry bytes = [WRITE_REG|CONFIG] bytes.append(SET_CONFIG) self.doOperation(writing(bytes)) time.sleep(LONG_PAUSE) #Collect print out the registers from the nRF to to make sure thay are allright self.ReadPrintReg(STATUS,"STATUS",1) self.ReadPrintReg(EN_AA,"EN_AA",1) self.ReadPrintReg(SETUP_RETR,"SETUP_RETR",1) self.ReadPrintReg(EN_RXADDR,"EN_RXADDR",1) self.ReadPrintReg(SETUP_AW,"SETUP_AW",1) self.ReadPrintReg(RF_CH,"RF_CH",1) self.ReadPrintReg(RF_SETUP,"RF_SETUP",1) self.ReadPrintReg(RX_ADDR_P0,"RX_ADDR_P0",5) self.ReadPrintReg(TX_ADDR,"TX_ADDR",5) self.ReadPrintReg(RX_PW_P0,"RX_PW_P0",1) self.ReadPrintReg(CONFIG,"CONFIG",1) #self.radio_pin.close() def Send(data): """Function that can be called from other files that wants to send data""" SendObj = NRF24L01P() SendObj.sendData(data) print("Enter data to send (3 bytes): ") #Retype the input-text (input is still on form main-loop) if __name__ == "__main__": """Gets called upon when running the file""" rxtx = input("rx or tx? \n") #Receiver or transmitter SendObj = NRF24L01P() #Start class if rxtx == "tx": #nRF transmitter print('\nTransmitter') SET_CONFIG = 0x1E #Transmitter SendObj.setupRadio() #Setting up radio #TCP-Server.Run_func() #Calls the "Run_func()" in a TCP-server (that in termes calls the "Send(data)" function above with the data) while 1: package = input("Enter data to send (3 bytes): ") #If not TCP-server is used, calls for input from user to bee sent print("") #print(package) bytesToSend = [ord(str(x)) for x in package] #Convert input to decimal values #print(bytesToSend) SendObj.sendData(bytesToSend) #calls the sendData() function with the payload else: #nRF receiver print('\nReceiver') SET_CONFIG = 0x1F #Receiver SendObj.setupRadio() print("\nReceiving data") i=0 while 1: SendObj.receiveData() time.sleep(SMALL_PAUSE)

TCP_Server.py
import socket import threading import socketserver import time import nRF24L01p class ThreadedTCPRequestHandler(socketserver.BaseRequestHandler): """Thread class""" def handle(self): while 1: try: data = str(self.request.recv(1024), 'ascii') #Receive bytes to from TCP-client to buffer of 1024 bytes cur_thread = threading.current_thread() #Get thread information print("Received: {} \n in: {}\n".format(data, cur_thread.name)) #Print out received bytes and thread name bytesToSend = [ord(str(x)) for x in data] #Convert received bytes to type: Decimal (ord("1")=49)Convert input to decimal values nRF24L01p.Send(bytesToSend) #Send the bytes to the nRF-program (transmitter) (in decimal form) self.request.sendall(bytes("{}".format(data), 'ascii')) #Resend the data to TCP-client except: break #Break from while-loop print("{} is now closed".format(cur_thread.name)) print("\nEnter data to send (3 bytes): ") #Retype the input-text (input is still on form main-loop) class ThreadedTCPServer(socketserver.ThreadingMixIn, socketserver.TCPServer): """Starts a new thread for each request""" pass def Run_func(): """Gets called on from nRF-script""" # HOST='' accepts all incoming ip HOST, PORT = '', 1234 #Setup server on different thread server = ThreadedTCPServer((HOST, PORT), ThreadedTCPRequestHandler) ip, port = server.server_address # Start a thread with the server -- the function will then start one # more thread for each request server_thread = threading.Thread(target=server.serve_forever) server_thread.daemon = True #Run in background thread = true server_thread.start() print("\nServer loop running in background thread!\n") if __name__ == "__main__": Run_func()


To run the program, create a third file, and name it to something like "a.sh", the ending "sh" means shell file, which is runnable. Fill the file with these commands:
(change the path "/home/pi/" to where you have the quick2wire-folder!)
export QUICK2WIRE_API_HOME=/home/pi/quick2wire-python-api-master export PYTHONPATH=$PYTHONPAT:$QUICK2WIRE_API_HOME python3 nRF24L01p.py
This will make sure the path is imported every time the script is run! If anyone knows how to permanently add the path, please tell me in the comment field!

To run the program, all you have to do now is to set the working path in the terminal to where you store the a.sh-file with the cd-command and type
$ sh a.sh

This is a screenshot from the code running in the terminal:

As you can see, the program starts by asking if you want to run it as "rx" (Receiver) or "tx" (transmitter). I chose transmitter by typing "tx"/enter.
Then it prints out all the registers that the code changes (or sets) and then starts a server loop in a background thread (TCP).
When this is done the program waits for either the user to type in data to send (3 bytes in my example), or for a command from the TCP-server.
In the picture above, you can see that i started by typing "123" on the keyboard, which was sent to the nRF and broadcasted to any nRF-receiver with address 0x12. As you can see the STATUS register after the broadcast tells me that the transmission failed (0x1E), since i don't have a receiver running at the moment... a working transmission would give the result "0x2E" (when the EN_AA is turned on)!

The second thing I did was to send the command "300" to the TCP-server from my home-made android application (can be sent form any TCP-client with the right port number). The TCP-server then calls the nRF24L01p.py and transmits the data like it was inputted with the keyboard.

If a (large) error shows up when you try to run the code, which tells you something about "cannot export the pin number 18 because it is already exported", run the following command in the terminal:

$ gpio-admin unexport 18

If an error shoes up that tells you that the address is occupied, the TCP-server has not closed yet, and you have to sit down and wait for up to 1min before you try again (I know you can change this timing, but haven't come so far)


If you have any questions or just want to tell me what you think of the blog, just give me a comment in the comment field underneath...
/Kalle