Finland1
post:x03170259
title
x03170259
body
A while a go I saw a neat article in Hackaday about a device that shows a picture that looks exactly the same looked from any direction. The idea is very simple: The picture is printed on a paper and placed inside the rotating cylinder. The cylinder has a narrow slit in it allowing the observer to only see a narrow section of the image at the time. When the cylinder rapidly rotates, observers brain parses the narrow sections to a whole image. Since the picture inside the cylinder rotates, it looks the same no matter which direction it’s looked at. In the end of July there’s my favorite festival Naamat held in Muurame, Finland. The nights in July start to be dark after the midsummers endless day. The major point of the festival is the party at night at the camping area. My tent has a plastic dome on top of it, so I got the idea to replicate this device and place it on top of my tent to make it stand out in the night. I thought it would be a one night task, but like with most of my ideas I ended up spending way more time with this that I intended. I started modeling the parts with Fusion 360. From top down, there’s the cylinder with the printed picture. The illusion works best when it’s well lit, so I made the top of the cylinder white from the inside to reflect the light back. The next part down is the rotor, where the cylinder is attached and which the motor rotates. Below that is the motor mount. The motor mount is essentially a white disc where the motor is fixed at the center. The light is provided by pieces of led strips glued to the disc. Again the white color is chosen to reflect the light inside the cylinder. After that there’s the bottom shell that has the electronics inside. The mounting on the tent dome is made by making a dome sized hole to the bottom of the shell and embedding three thread inserts to that the device can squeeze the dome on all sides. As for the electronics, there’s a RC ESC to control the motor speed and an Arduino mini that starts the motor with a fixed speed and then monitors the battery voltage. Not strictly necessary but I added a RC controlled switch to turn the light on and off. The rationale was that I wanted to be able to leave the device on for the whole night without destroying the lipo-battery by draining it completely. After power up, Arduino turns the light on, then waits for a few seconds for ESC to start and then it starts the motor at predefined speed. The rest of the time the Arduino is looping to check the battery voltage and when that falls below the set limit, the motor and the light is shut down. The idea is that the current draw after that is negligible and the battery can endure that for several hours. Boy were there a lot of those. I tried to make the cylinder as light as possible. When printing, I only used a single perimeter line with 0.6mm nozzle. To test that the idea works I printed only bare minimum parts, the cylinder and the rotor and tested just by holding the motor in my hand. When spooling up the cylinder, it immediately exploded to pieces in my hand. I re-printed the cylinder with walls twice as thick and tested again. I used a servo tester to find out the right speed. Somehow I had put the tester to full speed. Before I even had time to be scared the cylinder exploded again, fortunately missing my head. When I got tested so much that I saw the idea worked, I printed the motor mount. Since this was supposed to be a quick and dirty project, I tried to use the parts I had in my junk box(es, there’s a lot of those boxes. And junk). I thought I’d get a perfect motor from an old camera gimbal. Those are small, have a lot of torque and rotate slowly. The only problem was that my ESC refused to work with that motor. I then tried to use 400 class RC helicopter motor, but that spins way way too fast for this purpose. I finally settled with the regular 550 class brushed motor. The same you can find from any cordless drill. This made the device a lot more taller than I wanted but it works and at least the motors are widely available. Fortunately I also found an ESC for the brushed motor. Those are becoming uncommon too. Now that the cylinders were not exploding any more I noticed that the cylinder wobbled a lot. 3D-printing is not a tool for the tight tolerances. I thought that the mounting surface against the motor is not flat or the hole is not perpendicular to that surface. I printed a new part avoiding supports and with on purpose too tight hole. I then got my brother to flatten out the mounting surface and drill the right size hole with a lathe ensuring perpendicularity. This helped a lot but some wobbliness remains. This is likely because the slit on the cylinder, which makes the center of gravity to be somewhere else than the center of rotation. It also might act aerodynamically generating lift like a wing. The wobbliness don’t matter much but it makes the picture to appear a little fuzzy. The final issue I only found about at the festival. I was a bit skeptical about this working at all when there but it seemed to work well and draw interest. But soon it shut down even with a freshly charged battery. When restarted, it would work for a random time and again shut down. I realized the mistake I made. The loop that checks the battery voltage only looks at a single measurement result and if it’s below the limit, it turns the device off. With ADC readings, you should always assume that they are dirty and full of measurement errors. This was later fixed by taking a rolling average over multiple measurements. There’s one and perhaps the only event that my home city Jyväskylä can be proud of, the City of Light which in every autumn fills the city with ingenious and beautiful light installations. I thought this would suit well to the theme. I printed a small adapter which attaches to the handle of my boys bicycle chariot. The device was fixed to this adapter. Against all odds it worked perfectly for the whole evening even in quite bumpy bicycle ride and in a rainy weather. It was fun to see people trying to figure out what it is and wondering it aloud but still nobody came to ask My spouse got the idea that the dull gray inside of the hot tub cover might work well as a video projector screen. I remembered that my friend had an extra projector that I could have for a song, so why not try this out? The projector I got was a really flimsy Vivitek Qumi led-projector with meager 720p resolution, but on the upside it’s small and looks like that it might endure the extreme temperature changes here in Finland. The projector came with no mounting plate so the first thing was to design and print one. This was quite easy considering that the projector is really light and has a standard camera thread on the bottom. I came up with this design: https://www.thingiverse.com/thing:4796449 I needed some hassle free way of playing videos. The simplest approach would be to use the projectors in-build USB-player but it would probably only play a really small subset of videos and adding those would be cumbersome. With good experiences on prior project, I chose Raspberry Pi 4 as a computer and installed LibreELEC distribution to the smallest SD-card I could find from the parts bin. LibreELEC is a tiny Linux distribution containing only what’s needed to run Kodi, a popular easy to use home theater software. It boots fast and runs from a small SD-card. To mount the Raspberry, I printed my favorite enclosure from Thingiverse: https://www.thingiverse.com/thing:3714695. From the moment my spouse presented the idea, I had a clear vision what needs to be organized: A demo watch party for friends, so I collected computer demos from my favorite groups: ASD, Farbrausch, Fairlight and others. My spouse collected nature videos with relaxing music etc. We stored all the videos to our home server and instructed Kodi to automatically play a selection from the network share at startup. I fixed the projector under the eaves of our house where it would be safe from rain and only less than three meters away from the hot tub cover. The Raspberry case has VESA mounting points which were used to screw the case under the eaves. Our terrace has only one somewhat broken electricity outlet so that forced me to run an extension cord along the wall. The future improvement will be to run the cable inside the boarding. I put a remote controlled outlet between the extension cord and the outlet doubler to serve as an on/off switch for the whole system. The projector has its own power supply and I found an extra mobile phone charger to power the Raspberry (I used 4A supply and would not recommend using any less. Decoding videos takes a lot of juice). The picture showed up nice and bright enough in the early spring nights. Using the projectors zoom and trapezoid correction I got the picture to fill about all the space available in the cover. Even after adjusting, the picture is not perfectly sharp but for mostly playing abstract videos for ambience it’s fine to me. A water-proof Bluetooth speaker was used for the audio and controlling the Kodi when needed can be done using a Kore application on the Android phones. I was happily surprised how easily the project came together. That being said I did end up climbing up and down to the projector and adjusting the picture numerous times. The reasons were bad wifi speed and projector going to error mode. Wifi speed My mistake was to tidy the wires by fixing the projector PSU on top of the Raspberry with a zip-tie. The RF-emissions caused the wifi speed to be anything between 0.1 Mbps to 20 Mbps and making streaming videos from the home network painful. This was easily fixed by moving the PSU farther away from the Raspberry Projector shutting down I was a bit skeptic how the projector would handle the freezing cold weather. To my surprise it seemed to work in the minus five degrees weather. For a fifteen minutes. After that the projector started to blink the panel lights and according to manual indicating “CPU Fan fault”. Turning the projector off and on again resulted again 15min of use time before the same repeated. I took the projector apart and tried to clean it up. I could not see any obvious problems. After putting it together this problem happened only once. I’m not sure if this is really about the fan or just the cold weather. It’s now a bit warmer so that might have fixed it. If the problem reappears the next winter, I’ll probably just add a second remote controlled outlet to flip just the projector off and on again. After these issues were solved the installation has been working fine and endured outside already a month of quite terrible spring weather!The construction
The electronics
The problems
City of Light
The projector
The computer
The entertainment
Putting it all together
Not only dance and joy
With new R19 of Sigma 3D-printer, BCN3D added filament runout sensor. Upgrade kit can be purchased for older versions, but it also includes new extruders and nozzles driving price up to 600 €. I don’t know how much difference the new extruders and nozzles make and I’m pretty pleased with current performance of the printer, so I don’t see myself needing those. The runout sensor is another matter, it might save my long prints and help me use up all the spools, so I decided to make my own.
The sensor attaches to extruder. This way there’s no need to purge rest of the filament. The sensor is far enough that it recognizes runout before the extruder runs empty, but it’s near enough that if you start feeding the next spool, the extruder will grab from new filament in few seconds.
The sensor can be attached to Sigma extruder driver. The Sigma firmware has really nice functionality to handle runout, but unfortunately at least currently it does not do anything when printing from serial. Another way is to connect the sensor to Raspberry pi running Octoprint. I chose the latter as I have Raspberry built inside the case of Sigma and I never print from SD. I tried to hook the sensor to driver and Raspberry at the same time, but it does not work, probably because of conflicting pull-up resistors. This could be solver by a bit of additional electronics.
Print the sensor case and cover flat, no supports needed. The microswitch KW12-1.
Solder long enough wires (either short to driver board or long ones where you keep your Raspberry). Install the switch to case. Test with a piece of filament that the switch works. Put a short M3 socket head cap screw into its slot before closing the case with cover fixed with 2.6mm countersunk screws. Add two M3 locking screws, but leave them flush with inside.
Unscrew the extruder and take of the old lower guide tube. Shorten the tube and take of the locking nut from cut of tube and replace it shortened tube. This is hands down the most annoying task. I found out that squeezing the tube with pliers and using socket wrench helps.
Fix the sensor to extruder and lock the tube to sensor case with locking screws. Install the extruders to printer. Unfortunately the lower locking nut of the right extruder can’t be installed with the sensor but the extruder will stay put just as well with one nut.
Crimp the connectors to wires and and plug in the connectors either to extruder drivers of Raspberry and you are all set.
If you chose to use extruder driver, enable filament sensor from printer menu (before this, update the printer to latest firmware)
If you are using Raspberry and Octoprint, install filamentsensor-reloaded plugin. The plugins deserve a post of their own. There seems to be filamentsensor, filamentsensor-ng and filamentsensor-reloaded plugins, all of them more or less abandoned. I’m planning to improve the latter and add more sensible support for more than one extruder, but more on that later.
I can sell these sensors assembled and with connectors if you don’t want to spend time sourcing all the parts. Just drop me a message on comments below.
Download STL’s from: https://www.thingiverse.com/thing:3404631
]]>There’s a great local service in my home city Jyväskylä called Lastipyörälainaamo, where one can borrow electric bikes, cargo bikes and bike trailers for free. I’ve been thinking about buying a bike trailer to use with my son, so this was an opportunity to try one before buying.
They borrow the trailer with an electric bike, but I wanted to use my own. Since they don’t have extra hitch hooks and anyway the hook would not play well with the quick lock wheels (at least on my bike), I thought to make an alternate hitch.
This is how it looked like. My bike is Haibike SDURO SL.
]]>
I recently discovered WebRTC in another project and wanted to try it out in some home project. Since our another home project is nearing it’s delivery, a baby monitor seemed to be in the (very long) list of things to buy.
Our baby will probably be sleeping mostly outside in the baby carriage and I wanted some kind of device with live picture thats viewable anywhere in the house to keep an eye on him while doing something else. WebRTC seemed to fit the bill since it works wherever a recent enough browsed is available like in the Android tablet we have in the space between our kitchen and the living room. I tried to use ready software and 3D-printable parts wherever possible to make something usable fast.
The device is standard Raspberry Pi 2 with camera. Since Pi2 does not have
internal wlan like Pi3, I added an external adapter. TP-Link TL-WN725N was used for its small size.
For the microphone, I searched eBay and found seemingly perfect microphone that was about the size of the wlan adapter (see picture). When the mic finally arrived, the test was disappointing. The mic picked up interference probably from the wlan adapter so much that it was unusable.
After the second round at eBay I found good (read: cheap) alternative, but it had cumbersome gooseneck. Fortunately the gooseneck could easily be gutted out and the whole mic fitted inside the case. To save space, I soldered the mic circuit board directly to one of the usb connectors on the RPi.
Powering the device seemed a bit more difficult at first. Since this was supposed to be quick and easy project, I didn’t want to spent time making battery and charging circuit. Luckily, phone battery bank I owned (MyCharge Razor) had about the same footprint as RPi. To power the RPi one has to only connect the usb cable. As an added bonus, it can be charged with regular phone charger and it even has a charge indicator.
The software centers around Janus WebRTC gateway. Raspivid produces video to GStreamer, which streams the video to local udp socket. Janus reads the video and serves it to connected clients. Second GStreamer instance records audio from the microphone and streams it also to local udp socket which Janus listens. Finally Nginx webserver is there to serve the initial web page which the clients load.
Installing and configuring the needed applications are well documented here: https://planb.nicecupoftea.org/2015/07/28/hackspacehat-part-1-webrtc-janus-and-gstreamer/
I modified streamingtest.html web page in Janus examples so that the streaming will start when the page is opened. See vauva.html and vauva.js in the repository: https://github.com/JanneMantyharju/babymonitor
Finally the following commands were placed to /etc/rc.local to start the streaming on boot:
raspivid --verbose --nopreview -hf -ex nightpreview --width 640 \ --height 480 --framerate 30 --bitrate 1000000 --profile baseline \ --timeout 0 -fl -g 4 -o - | gst-launch-1.0 -v fdsrc ! h264parse ! \ rtph264pay config-interval=1 pt=96 ! udpsink host=127.0.0.1 port=8004 & gst-launch-1.0 alsasrc device="hw:1,0" ! audioamplify amplification=1 \ ! opusenc ! rtpopuspay ! udpsink host=127.0.0.1 port=8005 & /opt/janus/bin/janus -F /opt/janus/etc/janus/ &
During the testing, I wrote this small script to add a touch of realism in form of endless baby cry:
while true; do gst-launch-1.0 filesrc location=/home/pi/baby-crying-01.wav \ ! wavparse ! audioconvert ! audioresample ! opusenc ! rtpopuspay \ ! udpsink host=127.0.0.1 port=8005 done
For the case, I started with this awesome RPi case. For the camera, I made separate plate to fix the camera on (rpi-camera_plate.stl in the repository) and camera mount (rpi-camera_mount.stl), which fixes to the case screws. This way the camera angle can be adjusted.
The battery bank holder fixes to vesa mount points in the original case. The holder has a large clip on the other side. The baby monitor is meant to be attached to the hood of the baby carriage, so that the camera point down to the baby.
Since resulting device looked exactly something that engineer would come up with, Suvi wrapped it with comfy knitted sock with matching colors to the blanked on the carriage.
I’m really happy with the results. The project was quite straightforward, only problems were with the 3D-printer, which decided to act up when trying to print the clip. I have to admit that with the knitted sock, it doesn’t even look that bad!
]]>I had previously bought cheap sockets with a remote. These were branded “Opal” and cost next to nothing in a pack of two sockets and one remote and they seem to work well enough. Only minus was the strange 12v battery the remote uses.
I popped open the remote to check how it worked. The layout seems to be easy enough. The +12v from the battery is dropped to +5v for the microcontrolled under the epoxy blob. The controller scans the keypad and generates the code which is fed to RF part. The RF transmitter requires the +12v straight from the battery and operates in 433 MHz frequency. I cut the signal trace from the controller to the transmitter and soldered wires to the test pad in the signal trace and the ground. Using the oscilloscope I checked what the controller is outputting when the keys are pressed.
The signal seems to consist of preamble, 5 bytes of data and stop sign. The preamble is following:
480µs high
480µs low
480µs high
480µs low
3.4ms high
3.4ms low
After that, 40 bytes of data follows. Each byte starts with 440µs high, followed by 440µs low for 0-bit or 1.28ms low for 1-bit. The stop sign is single 440µs of high, before returning to low level. The remote always sends the same sequence five times for each key press.
For one of the keys, it gives the following data:
01011111
10000110
10100000
01111001
01001011
On my remote, first four bytes are always the same and only the last byte changes. To turn the socket of, last byte is inverted, so in this case to turn the same socket of, last byte would be: 10110100.
The following Arduino code listens the serial port for “1” or “0” character and turns one of the sockets on and off respectively:
#define CODE_SIZE 40 #define OUT_PIN 3 byte code_on[] = { 0, 1, 0, 1, 1, 1, 1, 1, \ 1, 0, 0, 0, 0, 1, 1, 0, \ 1, 0, 1, 0, 0, 0, 0, 0, \ 0, 1, 1, 1, 1, 0, 0, 1, \ 0, 1, 0, 0, 1, 0, 1, 1 }; byte code_off[] = { 0, 1, 0, 1, 1, 1, 1, 1, \ 1, 0, 0, 0, 0, 1, 1, 0, \ 1, 0, 1, 0, 0, 0, 0, 0, \ 0, 1, 1, 1, 1, 0, 0, 1, \ 1, 0, 1, 1, 0, 1, 0, 0 }; void write_rc(byte state) { digitalWrite(OUT_PIN, HIGH); delayMicroseconds(440); digitalWrite(OUT_PIN, LOW); if(state) delayMicroseconds(1320); else delayMicroseconds(440); } void send_preamble() { digitalWrite(OUT_PIN, HIGH); delayMicroseconds(440); digitalWrite(OUT_PIN, LOW); delayMicroseconds(440); digitalWrite(OUT_PIN, HIGH); delayMicroseconds(440); digitalWrite(OUT_PIN, LOW); delayMicroseconds(440); digitalWrite(OUT_PIN, HIGH); delayMicroseconds(3440); digitalWrite(OUT_PIN, LOW); delayMicroseconds(3440); } void send_stop() { digitalWrite(OUT_PIN, HIGH); delayMicroseconds(440); digitalWrite(OUT_PIN, LOW); } void send_code(int on) { int i; send_preamble(); for (i = 0; i < CODE_SIZE; i++) { if(on) write_rc(code_on[i]); else write_rc(code_off[i]); } send_stop(); } void setup() { pinMode(OUT_PIN, OUTPUT); Serial.begin(19200); } void loop() { int i; byte state; if(Serial.available() > 0) { state = Serial.read(); if(state == '1') { for(i = 0; i < 6; i++) { send_code(1); delay(20); } } if(state == '0') { for(i = 0; i < 6; i++) { send_code(0); delay(20); } } } }]]>
I have a Geeetech G2S 3D-printer, which features autoleveling out of the box. Unfortunately the autoleveling is pretty much a joke, consisting of piece of bended wire and a microswitch. Due to the wire flexing, the probe will get different values when the head is moving from left to right than from right to left.
I saw someone experimenting with the inductive proximity sensor for autoleveling. These sensors are usually used in applications like limit switches in the garage door openers. They aren’t designed for accuracy and thus I was a bit skeptic how it would work out. The sensors only detect metals, but for G2S it’s not an issue as it has a steel heat bed. Out of recommendation, I bought LJ18A3-8-Z/BX sensor from eBay. The benefit of this type of a sensor is the long detection range, which allows to position the sensor higher than the print head. This way there’s no need to manually lower and raise the sensor before starting the print. The downside is that the sensor needs +12v and also outputs the same voltage, so it can’t be directly connected to the endstop connector.
I spliced the supply wire from the power supply to power the sensor (brown wire is the positive and blue wire is the negative on the sensor). The easiest way to connect the sensor output to board is to connect 10 k ohm resistor between the sensor output (black wire) and the endstop pin. The sensor is NPN normally open type, so you need to invert the Z min endstop in the software.
The first version of the sensor mount was designed to be fixed to the spider to the same screw holes where the original probe microswitch was mounted. Unfortunately due to the size of the sensor the probing radius needed to be greatly reduced to avoid the sensor running over the platform. The second iteration of the mount places the sensor right behind the print head, which seems to work very well.
Here are the coordinates for the probe mount (you probably need to adjust the Z offset):
#define X_PROBE_OFFSET_FROM_EXTRUDER 0
#define Y_PROBE_OFFSET_FROM_EXTRUDER 28
#define Z_PROBE_OFFSET_FROM_EXTRUDER -1.4
Files:
Download STL files from: http://www.thingiverse.com/thing:1222949
]]>A while ago I bought a version of Kyosho Blizzard, which features the new iReceiver which lets you control standard servos and ESC’s with your tablet or mobile phone. There’s also a camera fixed to Blizzard’s fuselage for streaming video. I didn’t have high expectations about the video performance but for the video the range is really poor. For controlling, the range is what you would expect for wi-fi device, about 50 m. The application however stops streaming the video as soon as it detects even a slight packet loss, which generally happens after 20 m. The thought arose, that since mobile networks are nearly ubiquitous, how about tunneling the traffic via 3g connection?
Some device is needed, which acts as a VPN server and forwards the traffic to iReceiver. I used Beagleboard-XM for this, since it has multiple
USB ports. In this case two are needed, one for wi-fi adapter and one for 3g modem. Basically any Linux-running device would work, the performance does not play a role here. These instructions are for Ubuntu distro, but others would work too with some modifications. Trying this out also does not need you to modify your Blizzard in any way, except you need to strap the parts to it somehow (There’s nice flat space at the rear end of the model body).
Once you have your board booting and you have ssh access to it, the first task is to make the board to connect to Internet. For this 3g modem is needed. I used Huawei E230 for this since it seems to work with Ubuntu out of the box. Install wvdial, which does the “calling” to initiate connection
apt-get install wvdial
Edit /etc/wvdial.conf and put the following lines in it. You might need to change these, depending on your carrier. Google for proper settings. Note that you also need a connection, where you get real publicly accessible IP-address. In Finland only operator to offer this is currently DNA. There also might be some limitations which ports can be accessed. I use default ports in this post to keep it simple (NB. DNA also blocks most ports, so pay attention when setting up VPN). Also the SIM PIN is disabled for the sake of simplicity.
[Dialer dna] Modem = /dev/ttyUSB0 Init = AT+CGDCONT=1,"IP","internet" Phone = *99# Stupid Mode = 1 Username = " " Password = " "
Test that the connection works by starting the connection with “wvdial dna”
Since your operator issues dynamic IP address, which may change on each connection, we need to set up a dynamic host name to connect to your device. First, go and create account to one of the dynamic host services. I used DynDns. Install ddclient, which takes care of updating your IP address
apt-get install ddclient
The install process asks you about your selected service and user name, so you are all set after that.
First we need to find out your iReceiver name. They should all be unique, so multiple iReceivers can be in use at the same time. Install wireless tools
apt-get install wireless-tools
Power on your iReceiver to find out it’s name
iwlist scan
You should see something like this
Cell 05 - Address: 6C:71:D9:79:09:F8 Channel:8 Frequency:2.447 GHz (Channel 8) Quality=56/100 Signal level=56/100 Encryption key:on ESSID:"iReceiver7909F8"
Copy the ESSID and insert following lines to your /etc/network/interfaces file
auto wlan0 iface wlan0 inet dhcp wpa-ssid "iReceiver7909F8" wpa-psk "12345678"
Replace ssid with your essid. The password is always 12345678. Start the interface and check that it gets IP address from range 192.168.15.*
ifup wlan0
The VPN server is the essential part here. The Kyosho iReceiver application on your phone expects to be connected to the received via wi-fi and the receiver to be reachable at static ip-address. With VPN, we can create a tunnel to transport the data via Internet and at the same time make you phone to believe that iReceivers address is a local address, to which data can be sent directly. Generating various keys is the most laborious task and has been explained much better elsewhere, so go to this link https://help.ubuntu.com/community/OpenVPN and do the certificate and key generation for both server and client. Write following to /etc/openvpn/server.conf
# Change this if ISP blocks the default port port 1194 proto udp topology subnet # Client address range server 192.168.14.0 255.255.255.0 # Tell the client that 192.168.15.* network can be reached through VPN push "route 192.168.15.0 255.255.255.0" dev tun0 # Use correct key and certificate file names here ca ca.crt cert myservername.crt key myservername.key dh dh2048.pem ifconfig-pool-persist ipp.txt keepalive 10 600 comp-lzo persist-key persist-tun verb 3 mute 20 status openvpn-status.log client-config-dir ccd
Start the server with
service openvpn start
Even though the client can now send packets to the iReceiver, not all things work. The iReceiver address is 192.168.15.2 and it issues client addresses from .3 forward. The iReceiver accepts streering packets happily from any address and you could drive around with the Blizzard, but the video would not work. The reason is that iReceiver ignores the video start packet, unless it comes from subnet 192.168.15.*. Now our VPN client gets address from 192.168.14.* subnet. To make this work, we use iptables to setup IP masquerading so that every packet going to wlan0 device appears to be originated from 192.168.15.* subnet.
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
On your Android device, install OpenVPN client. On client application, there’s no way to enter settings manually, so we need to create settings file. Create client.ovpn file with following text. Copy and paste your keys and certificates you generated previously. Also replace the hostname with the one you created previously.
client dev tun proto udp remote yourdyndnshostnamehere 1194 tun-mtu 1454 nobind persist-tun comp-lzo verb 3 mute 20 auth-nocache <ca> contents of .ca file here </ca> <cert> contents of .crt file here </cert> <key> client key here </key>
After all the steps, trying it out is just starting VPN connection and launching iReceiver app. Drop a comment if there’s a bug in instructions, or some step needs clarifying! The same idea should work with any other wlan controller also, regardless of the brand.
]]>
List of workarounds:
I recently switched from Sports Tracker to Runkeeper, because the latter one offers integration with the Pebble smart watch. However both of those refused to work with my Polar heart rate sensor so I ended up with Endomondo. I wanted to keep the Pebble integration, but apparently even though that there are few threads in the interwebs requesting this feature, it does not seem to be in the list for now.
Endomondo does not offer any API to query information, but I noticed that when it’s not the active application it posts a notification with some very useful information. Since I heard that it’s possible for Android application to catch the notification messages posted by other programs, I decided to write my own adapter for Pebble.
It proved to be quite difficult to extract the sent information since it’s wrapped into RemoteView object, which does not provide any useful way to tinker with its contents. Finally I found an example from the Stack Overflow which gives an example how do this. Unfortunately the only way seems to be using introspection which is never recommended but seems to work.
The application gets the following information:
The information is sent to Pebble’s built-in sports application, so no extra application slot is used from the watch. Unfortunately the watch app is not customizable. It has a display for pace and speed and neither of those is available from Endomondo, so I’m reusing those fields for calories and pulse. User can toggle between these numbers by pressing the middle button on the watch.
The watch application will start automatically when Endomondo starts pushing notifications. The included Android app only displays some instructions and is required by the Play store. The actual program runs as a service on the phone and it needs to be given access to application notifications from the settings menu.
Application source code is available here: https://gitorious.org/pebblemondo
Installable application is available from the Play store against small support fee: https://play.google.com/store/apps/details?id=com.jannem.pebblemondo
Disclaimer: This application is not associated with Endomondo® or Pebble®
]]>