Archive for June, 2014
This mini tutorial shows how to generate custom Mobius strips with minimum effort. It demonstrates that python scripting can be used to ask the user for information and then apply it to a part the user is already working on. Hopefully that will be useful to some people when solving problems.
1. Download and install WizoScript 1.70 or later and start it.
2. Start Geomagic Design V16 hotfix 1 (126.96.36.19990) or later.
3. Create a new part and set the units to millimeters.
4. Create a new sketch on the XY plane.
5. Draw a triangle centered on the X axis and set the size of the reference circle to 10mm.
6. Set the center of the triangle 30mm from the origin and exit sketch editing mode.
7. Go to the WizoScript script library and copy the Interactive Mobius Strip Generator. Paste it into WizoScript. Hint: double-clicking on the script in the web-page selects the entire script.
8. Run the script.
9. You will be asked for the name of the part. Assuming you haven’t saved it enter “New Part (1)”. Then you will be asked for the name of the sketch. Enter “Sketch<1>”.
10. Next you will be asked the rotation point along the X axis. Enter “30”. This puts the rotation point at the center of the triangle.
11. You will be asked for the number of rotations. This is the number of times the mobius strip will completely rotate. Enter “3”.
12. Finally you will be asked to enter the number of steps. Enter “30”.
Now the mobius strip will be generated. Be patient as this can take several minutes. Here is what you should have:
Now it’s time to experiment! You can change the shape of the sketch to create different effects. Setting the rotation point closer or further away from the origin will create a “corkscrew” effect. You can increase or decrease the number of rotations. Reducing the number of steps will make the part faster to create but you might have to manually add a guide curve to get a true mobius strip.
Using this script it is possible to run it multiple times on the same part. For example create two sketches, run it on the first sketch and then run it on the second sketch to create two Mobius strips that are intertwined.
I think the jury is still out on the wind vane that comes with WH1080 weather stations (e.g. Fine Offset, Mapin). Some people claim it works fine when placed high up away from any buildings, trees or other obstructions. Many people complain that it is just not reliable regardless. It doesn’t help that the weather stations come with a short pole.
From watching the vane it seems one of the issues is when the wind is gusty. I’ve noticed that when a gust ends the vane becomes destabilized and simply spins around and around.
For me it is simply not feasible to locate the vane on the chimney so I wondered if adding software filtering to my weather station code might work.
pywws already contains wind direction averaging for hourly summaries so I thought it would give that a try. Here is how the wind direction data looked a few days ago before adding averaging to the code:
Here is the wind direction data today after adding the averaging:
Much better. It is clear the wind was coming out of the west. While the above data was being captured I could see the vane swinging from north to south all the time, so it is pretty nice that the averaging was able to pick out the correct wind direction.
As previously mentioned the algorithm was taken from pywws, but with a couple of changes added. It works as follows:
- When the receiver starts it collects a new wind vector every 48 seconds. The vector consists of the wind direction and average speed. This comes directly from the weather station transmitter.
- While the receiver is collecting the first 16 wind vectors it reports the current wind direction to Weather Underground. So for the first 12.8 minutes (16 x 48 seconds) after reset the wind direction is not averaged.
- Once 16 wind vectors have been collected the receiver starts averaging the wind direction and reporting the average to Weather Underground. Every 48 seconds when new data is received the oldest wind vector is overwritten. So the receiver always has the last 16 wind vectors to work with.
- The latest 16 wind vectors are converted into weighted vectors. There is one vector for each compass point direction and the size of each vector is the sum of the average wind speeds measured coming from that direction. This method ensures the result favors directions where stronger winds came from.
- Using some trigonometry the average wind direction is calculated.
- In the situation where there is no wind for all 16 wind vectors (so no wind for 12.8 minutes) then the last average wind direction is used.
The code can be obtained from github.
A couple of years ago I bought a WH1080 weather station (e.g. Fine Offset, Mapin). It’s available under many brands from many outlets all over the world and is very common. Here are pictures of what this cheap weather station looks like:
I had the touchscreen connected to a Linux sever via USB and used pywws to upload to Weather Underground. This worked well until USB broke so I had to look for a new solution.
Kevin Sangeelee had developed some code that allowed a Raspberry Pi to receive the 433MHz radio signals and decode them. It also had support for a pressure sensor. Perfect. The code can be found here: http://www.susa.net/wordpress/2012/08/raspberry-pi-reading-wh1081-weather-sensors-using-an-rfm01-and-rfm12b/
The RFM01 was obtained from Maplin for about £4 and was trivially connected to the RPi. Kevin’s article gives the connections. Note: I didn’t use any resistors.
The BMP085 was also easily connected. Purchased from eBay for about £6 it connects directly to the I2C pins. Again, no resistors needed.
The first step was up update Kevin’s code for revision 2 of the RPi. This is required because a GPIO pin has changed and the second I2C bus is now used.
Now I ran into a stumbling block – how to get the data into pywws. I hoped that this problem had already been solved but unfortunately I would have to start writing custom python modules. After thinking about it for a while I decided that all I needed was to upload data to Weather Underground. I didn’t need the other features of pywws. Fortunately Weather Underground has a simple way of uploading using a HTTP GET request. The data just needed to be massaged into the correct format. While I was at it I decided to use the rapid-fire updating. This means that Weather Underground displays new data from your station roughly every 48 seconds – you can watch it continually update.
You can get the code from GitHub here: https://github.com/ajayre/WH1080-Weather-Underground.
Create a text file in the same folder as the executable called wunderground_creds.txt. On the first line enter the name of your weather station ID, for example IWESTYORKS30. On the second line enter your Weather Underground password.
Compile, run and follow Kevin’s instructions for setting up and tuning. Don’t forget to enable the SPI and I2C modules on the RPi. Also make sure you run:
sudo dpkg-reconfigure tzdata
to set the timezone.
Make sure the path to the credentials file in wunderground.c is set correctly. To start the program on boot I used the following in a boot script:
sudo screen -d -m /home/pi/weather/wh1080_rf