I found a new way to scale STLs in FreeCAD where you don’t need to use the Python console.
Import the STL.
Go to the Part Workbench.
Select the STL in the Model list
Menu: Part->Create shape from mesh…
Select the new part
Menu: Part->convert to solid
Select the new part
Menu: Part->Refine shape
Change to the Draft Workbench
Menu: Draft->Clone
Now you can adjust the scale in the properties window of the clone.
Upverter has a nice STL export ( when it works ) of your board so you can do mechanical modelling for your design. Unfortunately when it gets imported into FreeCAD the scale is 10 times too small.
FreeCAD as of 0.15 does not have menu item that allows you to scale mesh imports. Luckily the python console can do the scaling of imported meshes.
First import the mesh ( STL file ) that you want to add to the current design. Select it in the “Combo view->Model” tree on the left of the FreeCAD screen. Then use the python console ( View->Views->Python console ) with the code below to scale it up 10 times.
import Mesh,BuildRegularGeoms mat=FreeCAD.Matrix() mat.scale(10.0,10.0,10.0) mesh=App.ActiveDocument.ActiveObject.Mesh.copy() mesh.transform(mat) Mesh.show(mesh)
Now you should have a correctly sized copy of the STL board that you imported.
Here is the original post on importing and scaling ( I wanted to scale a mesh I had already imported ).
I’ve had this Aerogarden for a while but most of it’s life has been spent in a box in the garage because the lights quit working shortly after the 1 year warranty ran out. I decided to take it out this weekend and figure out what the issue was.
I disassembled the the light fixture and pulled out the power board and there are 2 250V 3A fuses on there. Both of then were blown. I de-soldered those thinking I would just replace them and the board would work. Then I got to thinking why do I want to fix the power supply for the proprietary ( and not very long lasting ) bulbs so instead I hacked it to take A19 ( “standard” ) light bulbs.
I didn’t take pictures along the way but the hack is pretty simple.
I’ve currently got 3 60W incandescent grow bulbs in there but I’m on the lookout for some LED or CFL grow lights.
I was recently introduced to the MDBT40 module that is based on the Nordic nRF51822. The processor nicely solves a number problems I’ve been looking at and the fact that it’s Bluetooth Smart also solves how I’ll get the data from it.
I designed some custom hardware ( the picture at left ) around the module and I needed some way to program it. My earlier post shows my investigations with SWD and OpenOCD.I put a SWD header on the board to re-program it.
OpenOCD Configuration for the nRF51822
bishop on the Nordic Developer Zone figured out how to get the nRF51822 part working with S-Link and OpenOCD. I took his configuration and adjusted it to work with the bus blaster v3.
Save it as nrf51822.cfg so then you can start openocd with it.
OpenOCD defaults to a telnet interace on 4444.
The board is now prgrammed with your custom firmware. This should work with any MDBT40 based board the has the 12K programming resistor per the Raytac application note. It should also work with other nRF51822 based board with a SWD interface
A few months ago I went to upgrade my OpenPilot CC3D board an something went amiss and I ended up trashing the bootloader. I didn’t have a SWD dongle to reprogram it with so its been collecting dust. I just purchased a v3 bus blaster for a different project I’m working on and it has a SWD firmware so I thought I’d try and recover the CC3D. Below are the steps I used.
Download and install the latest OpenOCD
Re-flash the Bus Blaster v3 for KT-link buffer
The instructions below came from here
Getting/Building the bootloader
Now you need to get a bootloader to flash into the CC3D. You might be able to download bl_coptercontrol.hex but I’ve already got the OpenPilot development environment installed so I just built it using
If you don’t have the dev environment setup there are build instructions.
Here is the file I used bl_coptercontrol.hex but the regular disclaimers apply, if this file damages or bricks your CC3D I am not responsible.
OpenOCD config file
You need create a flashing script “cc3d-swd.cfg” to pass to OpenOCD.
Obiously replace “path_to_hex_file” to where you built or downloaded bl_coptercontrol.hex
Connect the bus blaster to the CC3d
I got the cable connections from here.
Finally reflashing the CC3D bootloader
I created some CAD drawings for quadcopter parts I kept breaking. I got tired of making and cutting out the fibreglass myself so I created some Oshpark boards.
You can go here to order your very own Quadcopter parts
Here’s what the first batch looked like. I didn’t like the look of the power board so I did a new layout for my second batch.
I’ve tried the screw positions with the KK multirotor board and the CC3D flight control board.
I recently got my amateur radio certificate and was interested doing some APRS messaging so I purchased a Sainsonic AP510. It’s a nice little TNC with GPS, bluetooth and a thermometer.
It comes with minimal documentation in 4 languages and no software to configure it.
There’s a Yahoo Group that has firmware, configuration software and upgrade software. It’s annoying that you need to sign up for a Yahoo account to download the files there.
There’s also a Chinese website that has more firmware and some forums ( the Yahoo site has mined most needed data from there )
There’s also a good French website that explains how to flash the firmware and has some files needed for windows 7.
I found a German site that explains the serial cable pinout.
Upgrading the firmware
Standard disclaimer: this has worked for me but if it fails and bricks your AP510 I’m not responsible.
So far I have only gotten this to work on Windows, it will run under Wine but won’t connect. On windows XP these files AVRTTupdata.exe.zip and the VB6 runtime will be enough. On any newer windows MSCOMM32.OCX and MSSTDFMT.DLL will be required as well.
Make sure the ini file is in the same directory as the AVRTTupdata when you run it as it has the correct setup for the AVR in the AP510. The first time you run AVRTTUpdata it will be in Chinese, select language and put it into English.
Voila your AP510 is now upgraded.
Linux Configuration tool
Update: This is deprecated use chirp instead as it now supports the AP510
The windows configuration tool is in the archive above. I didn’t want to start up a VM each time to change the config so I wrote a simple python tool AP510-setup to configure it. You’ll need to edit the script to change the comport, callsign and other settings. I’ve licensed it GPL V2 and please send me any improvements you make to the script.
To use the script:
EDIT: Jan was nice enough to reverse engineer a schematic for the AP510.
I figured out how to read and write the i2c bus on the imWatch so I can now sample at whatever rate I’d like. This tarball includes code that should work upto 200Hz without overloading the processor.
Faster rates should be possible but it would mean getting the FIFO in the accelerometer working and then backdating the samples.
Building the JNI
I’m not going to detail how to use a JNI within an Android project. there are plenty of other tutorials out there.
From the tarball put “akkea-jni.c” and “Android.mk” into the jni directory of your android >project. Then run
ndk-build
You should get output similar to below.
Compile thumb : akkea-jni <= akkea-jni.c SharedLibrary : libakkea-jni.so Install : libakkea-jni.so => libs/armeabi/libakkea-jni.so
Using the Accelerometer JNI code
Add these native prototypes and constants to your android code.
public native int readAccel( SeismoVector vector, int fd, long startTime ); public native int openI2c( String path ); public native void closeI2c( int fileHandle ); public native int i2cReadReg( int file, int addr, int reg); public native int i2cWriteReg( int file, int addr, int reg, int val); int i2cHandle; final byte ACCEL_I2C_ADDR = 25; final int ACCEL_RATE_OFF = 0; final int ACCEL_RATE_1HZ = 1 << 4; final int ACCEL_RATE_10HZ = 2 << 4; final int ACCEL_RATE_25HZ = 3 << 4; final int ACCEL_RATE_50HZ = 4 << 4; final int ACCEL_RATE_100HZ = 5 << 4; final int ACCEL_RATE_200HZ = 6 << 4; final int ACCEL_RATE_400HZ = 7 << 4; final int ACCEL_RATE_1_6KHZ = 8 << 4; final int ACCEL_RATE_5KHZ = 9 << 4;
The I2C bus and accelerometer need to be setup
public boolean openI2C() {
try
{
Runtime.getRuntime().exec("chmod 777 /dev/i2c-0");
} catch (IOException e) {
e.printStackTrace();
}
i2cHandle = openI2c( "/dev/i2c-0" );
if( i2cHandle <= 0 )
return false;
int[] arr = new int[4];
for( int i=0; i<128; i++ ) {
arr[0] = i2cReadReg( i2cHandle, ACCEL_I2C_ADDR, i );
if( arr[0] != 0 )
Log.d(TAG, "Register " + String.valueOf( i ) + " = " + String.valueOf( arr[0] ));
}
int val;
val = i2cReadReg( i2cHandle, ACCEL_I2C_ADDR, 0x20 );
val = ( val & 0x0F );
switch( HZ ) {
case 1:
val |= ACCEL_RATE_1HZ;
break;
case 10:
val |= ACCEL_RATE_10HZ;
break;
case 25:
val |= ACCEL_RATE_25HZ;
break;
case 100:
val |= ACCEL_RATE_100HZ;
break;
case 200:
val |= ACCEL_RATE_200HZ;
break;
case 400:
val |= ACCEL_RATE_400HZ;
break;
case 1600:
val |= ACCEL_RATE_1_6KHZ;
break;
}
i2cWriteReg( i2cHandle, ACCEL_I2C_ADDR, 0x20, val );
val = i2cReadReg( i2cHandle, ACCEL_I2C_ADDR, 0x20 );
Log.d(TAG, "Register Rate " + String.valueOf( val ));
return true;
}
I then use a TimerTask to read the accelerometer at whatever rate I want.
class sensorTask extends TimerTask {
@Override
public void run() {
long time;
if( index >= totalSamples ) {
Log.d(TAG, "index past end of array");
return;
}
SeismoVector vector = new SeismoVector();
time = readAccel( vector, i2cHandle, startTime );
if( startTime == 0 )
startTime = time;
vectors[index++] = vector;
}
};
I purchased the X230 Quad copter kit from hobby king in December. I’ve been learning to fly it and in the process have been breaking parts.
Hobby king doesn’t sell replacement parts so I’ve been patching it up as I go along. Some of the pieces are getting too broken to be patched. I’ve created a DXF of the parts and I’m going to have them built out of carbon fibre for increased crash resistance 🙂
At left is a 1:2 jpeg of the parts. If you’d like the DXF it’s here
If you’d like the SVG it’s here
Edit: I don’t recommend using carbon fibre to prototype this unless you have a laser cutter.
About a year ago I was contacted to write some iOS software to measure tremor in MS patients. I have no interest in writing iOS software. The only real hardware requirement was that the device had an accelerometer so I suggested using an Android device instead. The device would need to be fastened to the patients arm and be lightweight to limit it’s influence on the tremor. The perfect fit seemed to be an Android watch.
There were two capable Android watches available at the time, the WiMM One module and the i’m Watch. The WiMM One was already shipping, had stock and a price point less than half of what the I’m Watch was going for. At the time the i’m Watch was taking pre-orders with a promise of shipping soon.
I ordered a few of he WiMM modules and got to work writing the beta software on a Nexus S. I demoed the first version two weeks later.
The Software
Once the demo proved that I could get the desired sample rates I started shrinking it down and learning the WiMM API. Most of the differences lie in the way that the application screens are laid out. That allowed me to keep most of the functional code from the demo application.
The application is very simplistic from a GUI perspective in that it only displays a single button and a countdown timer. This is partly because the application needs limited user feedback but it’s also due to potential users of the application. One of the uses would be to monitor outpatients to track their tremor over time without requiring a clinic visit. These users would have limited eye hand coordination so the simpler the interface the better.
Another reason for targeting the WiMM device was it included wifi that would allow automated data collection. After collecting a data series the watch would connect to a server to upload the data. Once uploaded the data would be saved as a CSV. Then GNUplot was used to transform the CSV into a line graph of the X, Y and Z axes. After the data gets plotted the server also does an FFT and plots that. The FFT is done to expose any frequency elements in the tremors.
This is an example of the post processed data
Challenges
There were a number of challenges with using the WiMM watch. I was familiar with Android 1.6 but the version on the WiMM is slightly modified for the smaller screen and other hardware peculiarities.
On of the challenging differences is the watch doesn’t follow the Android sensor API for the accelerometers. You are able to set a rate using the defines SENSOR_DELAY_FASTEST, SENSOR_DELAY_GAME and SENSOR_DELAY_NORMAL however you can’t specify an absolute rate for updates. To get around this issue I sampled at the highest rate possible ( 200Hz ) and decimated the samples I didn’t need.
Using this technique I was able to get 100, 150 and 200Hz sample rates. For the most part this did work well but rates over 100Hz still had problems. There were occasional gaps in the data that lasted upto 120ms. After some investigation I found the Dalvik GC was logging with times that were amazingly close to some of the gaps in my data.
02-28 17:14:14.605: D/dalvikvm(1843): GC freed 8725 objects / 544128 bytes in 92ms
By pre-allocating as many of the accelerometer data structures as possible I reduced the number of garbage collection cycles and the subsequent spaces in the data. Even once I solved this there are still the occasional gaps. My best guess at this point is that the accelerometer and the GUI are running at the same priority and occasionally collide.
Successes 
The table at left shows a comparison between the WiMM module and a Entran accelerometer. The WiMM is sampling at 100Hz and the Entran around 2KHz. The data shows that the WiMM compares quite well to the standard analog sensor.
Tremors in people are well below the 50Hz that the WiMM should be able to resolve so it would function as an acceptable measurement device for in or out-patients with temors and tremor related diseases.
Data is starting to come in from the studies using the software. It is showing some interesting repetitive osculations which we expected. At right is an excerpt from a MS patient recorded during a clinic visit.
There are currently 2 studies using the software, below is a synopsis of their work. Both of them should be publishing some of the results soon.
Study #1
Traditional tools for accelerometry are cumbersome and do not lend themselves to routine clinical use. Using a smart watch device for accelerometry makes data collection very simple and portable, and may allow for wider use of accelerometry for tremor analysis. The potential of the on-board hardware for data processing and display makes this even more exciting. As a proof of concept, I am collecting accelerometer data simultaneously from the WIMM One and a standard analog accelerometer, and coanalyzing the data offline in the MATLAB environment to determine whether the performance of the WIMM One is acceptable. After this, I am collecting data from patients with Parkinson disease and Essential tremor to compare some aspects of these tremors to see if the portable device might be a useful diagnostic tool.
Daryl Wile, MD, MSc
Neurology Resident
University of Calgary
Study #2
As a clinician-scientist, I envision both clinical and research-oriented applications for watch-based accelerometry in the evaluation of tremor in Multiple Sclerosis (MS).
Clinically, I frequently encounter tremor in MS (MST). It is notoriously difficult to treat, meaning that patients need to try many interventions before (if ever) we find one that works. This problem is compounded by: (1) patient mobility and transportation issues – it is difficult and inconvenient for patients to return to the clinic frequently for re-evaluation of treatment efficacy, and (2) clinic availability – usually, I can only follow-up with patients every six months.
In research trials, it is necessary to have patients return frequently to the clinic for re-evaluation (which is problematic), and it is ideal to have a simple technique for quantifying tremor response to treatment.
By collecting tremor data remotely, treatment efficacy can be evaluated quickly, quantitatively, and conveniently. In clinical terms, this means we waste little time finding a treatment that works. In research terms, this allows us to objectively evaluate, with minimal inconvenience to the patient, potential new therapies for treating MST.
Scott E Jarvis MD PhD FRCPC (Neurology)
MS Clinical Fellow
University of Calgary
Future Directions
WiMM has gone dark about what their future holds and has stopped selling the devices. They have also dropped all developer support.
This is where the i’m Watch comes into play. I’ve managed to reverse engineer the accelerometer and magnetometer in the watch and I’m currently rewriting the application to work on the new device. I’ve already written a native i2c library that can get data from the watch and it is sampling at 100Hz.
Next I’ll need to establish the accuracy of the new accelerometer so it can be used to replace the WiMM watch.
Wishlist for future releases
Use the form below if you’d like to contact me or either of the Doctors running the studies.
