petertux

Hi to all,
are you interested  in assembler language programming? if so, this could be of interest to you.
the basic idea is a 5kB kernel embedded on a MSP430FRxxxx, capable of downloading source files, interpreting and compiling them.  Associated with a minimalist IDE: a text editor, a generic preprocessor and a terminal to communicate with the embedded kernel.
What is the craziest wish of a microcontroller programmer? In my opinion, it would be that once his source is modified, he clicks on the "build" shortcut of the editor and in a second, the program is compiled on the target, ready for testing. It's impossible, of course. But...
You have an MSP-EXP430FRxxxx launchpad plus an USB-UART bridge sleeping at the bottom of a drawer, and some COVID19 containment time to use? try this:
FastForth For MSP430fr5xxx
I hope you'll find at least some good ideas there.
 

If you appreciate late 90s vintage PCs you might be interested in this one.
I decided to build a Pentium II machine on which I can play my favourite games from those times. Magic Carpet (Bullfrog Productions) is one of them, but it needs a joystick. I had good quality USB joysticks, but those games need old analog gameport-based controllers that are serviced by the sound cards of the time.
This new project acts as a USB Host and provides the analog output that emulates a 4 axis + 4 button game controller.
the prototype works absolutely great, it takes about 0.6ms to read data from the attached USB joystick and to send it to the sound card. data is retrieved every 10ms as per the HID polling interval, absolutely no input command is lost and there is over-current protection built in in order to protect the PC from misuse.
what do you guys think? I'm open to ideas regarding this project before I commit revision 2 of the board - which might end up being a 4 layer design.
prototype pictures: https://photos.app.goo.gl/fXdDBng4dvEepq8V7
repo: https://cadlab.io/projects/lemidi
cheers,
peter

If you appreciate late 90s vintage PCs you might be interested in this one.
I decided to build a Pentium II machine on which I can play my favourite games from those times. Magic Carpet (Bullfrog Productions) is one of them, but it needs a joystick. I had good quality USB joysticks, but those games need old analog gameport-based controllers that are serviced by the sound cards of the time.
This new project acts as a USB Host and provides the analog output that emulates a 4 axis + 4 button game controller.
the prototype works absolutely great, it takes about 0.6ms to read data from the attached USB joystick and to send it to the sound card. data is retrieved every 10ms as per the HID polling interval, absolutely no input command is lost and there is over-current protection built in in order to protect the PC from misuse.
what do you guys think? I'm open to ideas regarding this project before I commit revision 2 of the board - which might end up being a 4 layer design.
prototype pictures: https://photos.app.goo.gl/fXdDBng4dvEepq8V7
repo: https://cadlab.io/projects/lemidi
cheers,
peter

If you appreciate late 90s vintage PCs you might be interested in this one.
I decided to build a Pentium II machine on which I can play my favourite games from those times. Magic Carpet (Bullfrog Productions) is one of them, but it needs a joystick. I had good quality USB joysticks, but those games need old analog gameport-based controllers that are serviced by the sound cards of the time.
This new project acts as a USB Host and provides the analog output that emulates a 4 axis + 4 button game controller.
the prototype works absolutely great, it takes about 0.6ms to read data from the attached USB joystick and to send it to the sound card. data is retrieved every 10ms as per the HID polling interval, absolutely no input command is lost and there is over-current protection built in in order to protect the PC from misuse.
what do you guys think? I'm open to ideas regarding this project before I commit revision 2 of the board - which might end up being a 4 layer design.
prototype pictures: https://photos.app.goo.gl/fXdDBng4dvEepq8V7
repo: https://cadlab.io/projects/lemidi
cheers,
peter

Hello everyone,
 
There is a couple of similar projects available on the internet. Some of them base on Arduino and PIC performs very basic mount control without math intensive computation implemented in embedded controller. I decided to build my own with the following goals:
ease of use by an inexperienced amateur astronomer (full automatic operation) precision and resolution of position  last but not least: the price Final, or better say at the moment, design comprises of the following components:
Stellaris LM4F launchpad central control unit, two ULN2003 unipolar stepper motor driver chips, two 28byj-48 stepper motors one moving in azimuth, and in elevation via gear train, communication module: Bluetooth serial module. It allows sending a coordinate set-point and provides position feedback to Stellarium, GPS module providing position and precise time reference - PPS gives 1us accuracy, Nokia 5110 display unit and joystick for standalone operation, now obsolete mouse (PS/2) modified to provide independent (incremental) position information Resolution that was reached is a single step of approx. 5". Given the size of Jupiter to range from 30" to 50", this positioning resolution makes the view comfortably stable in standard 60° FOV eyepiece at reasonably high magnification, without the need to adjust AZ/ALT continuously.
 
During the development I made use of several opensource and projects available online, namely:
AccelStepper for stepper control, TinyGPS++ for NMEA decoding, Arduino telescope controller was my inspiration and reference for Taki's matrix method for coordinates transformation, of course Energia as my IDE Upon power-up the mount is performing:
homing acquisition of current location (longitude/latitude) and time via NMEA stream moves to 3 brightest (most convenient) stars in succession to perform 3 star alignment procedure - they are selected from the list of over 500 stars in built-in catalog (the  brightest are used for the alignment, tough), once aligned the mount is in tracking mode: it tracks the view to counter the apparent movement of objects in the sky, waiting, either for the user to move to particular object - selected from the library of stars and Messier objects, or awaits connection via Bluetooth from a PC running Stellarium with a plugin and slews to selected object. search for the object that should be visible in the eyepiece and display important information on LCD - I compiled in 500 brightest stars from HYGXYZ and full Messier catalog.  I have very little experience as amateur astronomer so far, so some of the objectives might have been not very obvious for me in the beginning. This project was also a good way to make use of my free time and gain experience in embedded system design.
 
With kind regards,
Szymon
 

you can have a look at an older project of mine here:
 
https://github.com/rodan/tracy
 
all the code is interrupt driven, no blocking calls, two different uarts are used. and it works nicely as an always-online tracker, it has more than an year uptime mounted on my motorcycle.

you can have a look at an older project of mine here:
 
https://github.com/rodan/tracy
 
all the code is interrupt driven, no blocking calls, two different uarts are used. and it works nicely as an always-online tracker, it has more than an year uptime mounted on my motorcycle.

you can have a look at an older project of mine here:
 
https://github.com/rodan/tracy
 
all the code is interrupt driven, no blocking calls, two different uarts are used. and it works nicely as an always-online tracker, it has more than an year uptime mounted on my motorcycle.

One of the most interesting aspects of selling your widget is seeing how other people use your product and what their requirements are.
 
dAISy was originally built for ship-geeks that are entertained for hours with MarineTraffic (like myself). I also broke out a few pins for tinkerers that want to connect dAISy to other widgets (again, like myself). Turns out, the majority of my customers are boat owners (unlike myself).
 
Boaters use dAISy to keep track of ships around them for navigation purposes, i.e. avoiding collisions. Free software called OpenCPN turns a laptop (or a RaspBerry Pi for the more geeky faction) into a chartplotter, a device that typically costs $500+. dAISy is connected via USB and provides real-time information about nearby ships. However, many boaters already have a traditional chartplotter and want to connect these with dAISy for AIS input.
 
Most chartplotters talk NMEA 0183, a serial standard compatible with RS-422. Unfortunately, that's not the same as the UART serial output of dAISy. Which leads to NMEA output as the 2nd most requested feature for dAISy (right after native WiFi*).
 
Electronic tinkerers can convert dAISy's TX output into a signal that works with some (most?) NMEA 0183 consumers using an NPN transistor and two resistors:

Exact resistor values don't matter that much, as their purpose is mostly to limit current. Slightly higher values should work as well.
 
Besides not being really NMEA/RS-422 compliant, requiring to solder obviously is a non-starter for the majority of my customers. So I decided to look for an integrated, more polished solution.
 
First step is implementing proper RS-422 driven from dAISy's serial output (TX). Luckily there's a chip for that. Well, there are many, but I settled for the TI UA9638.

 
As I didn't want to change dAISy's main PCB (NRE, the bane of mass production), I designed a PCB that screws to the backside of the existing enclosure. On the inside of the PCB is the RS-422 driver and a connector for a cable to the main PCB. The cable is soldered to existing breakout pads for TX, 5V and GND. Still on the inside, I also added a DC/DC converter so that dAISy optionally can be powered from the boat's 12V power system instead of USB. On the outside of the PCB is a beefy screw terminal to connect NMEA 0183 and 12V wiring.
 
Here is a picture of the first iteration I built today. The PCB on the left shows the inside, with DC/DC converter and related passives still unpopulated.

 
The NMEA 0183 output works as expected. I'm not sure yet about including the DC/DC converter in the final design. I'm worried that having a switching power supply inside the enclosure will introduce noise and interfere with the radio's performance.
 
I plan to add this or a similar design to my Tindie store early next year. In the meantime, any volunteers that have a chartplotter and dAISy and want to test the add-on should contact me.
 
*Besides being wireless, WiFi is popular because it's the only way to get real-time NMEA data to the iPad. Unfortunately, iOS devices do not support USB or Bluetooth from devices not approved by Apple. Today, dAISy either requires a Raspberry Pi (running Kplex or similar) or some tinkering with an ESP8266. Once it has native NMEA output, dAISy will also work with NMEA routers, some of which include WiFi.

Watch The Story of Energia in 150 Seconds.
 

There is a newlib-nano option I have heard of when building newlib although I don't know offhand how to enable that.

Some time back I ordered an INA125P Instrumentation Amplifier in order to fool around with a cheap, broken "postal" scale that I had.  It arrived and I promptly put it away and forgot it about it.  So the other day I was digging through my junk box, saw the scale, and decided to tear it apart.  Since it is getting near Halloween, and I knew my grandchildren would be interested, I wrote a little sketch in Energia to estimate the amount of candy in a bowl.
 
Here is a schematic of the circuit.  It "works" but given my skills it may not be best.

 
This being a MSP430 project I hooked up the sleep pin on the INA125P.  I also made it where I could change out Rg, the gain controlling resistor, easily.  Once I had it working I made up a little BoosterPack that goes on the bottom of the LaunchPad. 

The INA125P sits between the daughter board and the MSP430F5529 LaunchPad - you are looking down on the male pins in the photo above.  I hot glued a piece of cardboard on the bottom so as to reduce the chance of shorts and provide a reminder on how to connect it.  Below is a view from the bottom with it connected up to the LaunchPad and the scale.

The sketch is here on github.  There is a little calibration routine it goes through when started up where it asks for the empty bowl and then a known quantity of candy to be placed into it.  After that, it displays on a SHARP96 BoosterPack.

I thought about connecting it up to the IOT, but after due consideration decided I didn't want the neighborhood kids knowing how much candy I have left.

Batteries last about 2 months.  The gears show no real wear after over a year.  The ratchet wheel gets the most wear but has held up well.  The larger gears (wheels) are made from Baltic birch plywood and are quite stable. 

This pendulum clock is not only regulated by the pendulum, but it is driven by it.  A hidden magnet in the pendulum swings past a hidden coil and induces a current.  This is detected and then a current pulse is fed into the coil, creating an electromagnet that repels the pendulum to keep it moving.
 
Others have designed and built clocks like this, but as far as I know mine is the only one using a microcontroller to fine-tune the pendulum's speed to keep accurate time. 
 
The coil's output is filtered and fed into an MSP430 comparator, set on an interrupt to wake the microcontroller up.  The microcontroller delays a bit to let the magnet swing away from the coil some for optimal push, then feeds a variable-length pulse (typically 25 mS) into the coil via an output port connected to a PNP transistor.  If the pulse duration is increased, the pendulum swings farther and slows down.  If decreased, the pendulum speeds up.  The ratchet mechanism used to convert pendulum motion into rotary motion had to be designed to accommodate this variation in pendulum swing angle.  By varying the pulse width, the clock can be sped up or slowed down about 1%.  The pendulum needs to be manually adjusted, by setting the height of the bob, to within this tolerance.  To facilitate that, I use a dual-color LED driven by two output ports.  The LED flashes red if the pendulum is too slow, and green if it is too fast.  It usually takes only a few minutes to adjust the bob.  
 
Once the bob is set, the microcontroller can maintain accuracy.  I've implemented a modified PID (proportional - integral - derivative) control system to derive the pulse width and regulate the clock. Accuracy is basically the same as the watch crystal used to drive the timer/counter. 

here's my latest project, a fully open-source msp430f5510-based gps/gprs tracker. it's a device that wakes up every few minutes and does the following:

 - tries to get a gps fix
 - connects to the gsm network, marks the tower cell ids it talks to
 - executes sms commands received - if any
 - starts a gprs connection and sends all the info it has collected via http to my server

it does all this only based on interrupts (zero blocking functions are used - all the similar projects I've seen are riddled with delay()s).
functions that fail due to network unavailability are retried a given number of times.

the data received on the server is placed into a database and gps positions of the cell towers are obtained for future triangulation. this info can be used if there is no gps coverage due to obstacles.
 


to give a little context, I felt the need of making my own tracker because I bought something like this an year ago and quickly became dissapointed by the dubious quality of the hardware design and software of the product.

here is the first prototype - the magnet wire was used to debug the hardware flow control-enabled UART of the sim900.



the first assembled module is ready to be used on my trip to Greece. instead of a small flat LiPo I ended up using 2 cells from a discarded laptop battery - there was no time to wire this to my motorbike. now after ~20 days it is still tracking.



I am pretty happy with this first revision, but I'm working on the next one that will include a small serial fram chip. I decided to use that as a buffer because of the weird way the mobile phone company is counting the gprs traffic.

for some more eye-candy, you can see my route from home to Ouranoupoli on a google-map overlay here:
http://www.simplex.ro/files/trips/test.html
 
waypoints are 10 minutes apart, the trip took 10 hours and about 800km.

project home: https://github.com/rodan/tracy
 

 

here's my latest project, a fully open-source msp430f5510-based gps/gprs tracker. it's a device that wakes up every few minutes and does the following:

 - tries to get a gps fix
 - connects to the gsm network, marks the tower cell ids it talks to
 - executes sms commands received - if any
 - starts a gprs connection and sends all the info it has collected via http to my server

it does all this only based on interrupts (zero blocking functions are used - all the similar projects I've seen are riddled with delay()s).
functions that fail due to network unavailability are retried a given number of times.

the data received on the server is placed into a database and gps positions of the cell towers are obtained for future triangulation. this info can be used if there is no gps coverage due to obstacles.
 


to give a little context, I felt the need of making my own tracker because I bought something like this an year ago and quickly became dissapointed by the dubious quality of the hardware design and software of the product.

here is the first prototype - the magnet wire was used to debug the hardware flow control-enabled UART of the sim900.



the first assembled module is ready to be used on my trip to Greece. instead of a small flat LiPo I ended up using 2 cells from a discarded laptop battery - there was no time to wire this to my motorbike. now after ~20 days it is still tracking.



I am pretty happy with this first revision, but I'm working on the next one that will include a small serial fram chip. I decided to use that as a buffer because of the weird way the mobile phone company is counting the gprs traffic.

for some more eye-candy, you can see my route from home to Ouranoupoli on a google-map overlay here:
http://www.simplex.ro/files/trips/test.html
 
waypoints are 10 minutes apart, the trip took 10 hours and about 800km.

project home: https://github.com/rodan/tracy
 

 

here's my latest project, a fully open-source msp430f5510-based gps/gprs tracker. it's a device that wakes up every few minutes and does the following:

 - tries to get a gps fix
 - connects to the gsm network, marks the tower cell ids it talks to
 - executes sms commands received - if any
 - starts a gprs connection and sends all the info it has collected via http to my server

it does all this only based on interrupts (zero blocking functions are used - all the similar projects I've seen are riddled with delay()s).
functions that fail due to network unavailability are retried a given number of times.

the data received on the server is placed into a database and gps positions of the cell towers are obtained for future triangulation. this info can be used if there is no gps coverage due to obstacles.
 


to give a little context, I felt the need of making my own tracker because I bought something like this an year ago and quickly became dissapointed by the dubious quality of the hardware design and software of the product.

here is the first prototype - the magnet wire was used to debug the hardware flow control-enabled UART of the sim900.



the first assembled module is ready to be used on my trip to Greece. instead of a small flat LiPo I ended up using 2 cells from a discarded laptop battery - there was no time to wire this to my motorbike. now after ~20 days it is still tracking.



I am pretty happy with this first revision, but I'm working on the next one that will include a small serial fram chip. I decided to use that as a buffer because of the weird way the mobile phone company is counting the gprs traffic.

for some more eye-candy, you can see my route from home to Ouranoupoli on a google-map overlay here:
http://www.simplex.ro/files/trips/test.html
 
waypoints are 10 minutes apart, the trip took 10 hours and about 800km.

project home: https://github.com/rodan/tracy
 

 

here's my latest project, a fully open-source msp430f5510-based gps/gprs tracker. it's a device that wakes up every few minutes and does the following:

 - tries to get a gps fix
 - connects to the gsm network, marks the tower cell ids it talks to
 - executes sms commands received - if any
 - starts a gprs connection and sends all the info it has collected via http to my server

it does all this only based on interrupts (zero blocking functions are used - all the similar projects I've seen are riddled with delay()s).
functions that fail due to network unavailability are retried a given number of times.

the data received on the server is placed into a database and gps positions of the cell towers are obtained for future triangulation. this info can be used if there is no gps coverage due to obstacles.
 


to give a little context, I felt the need of making my own tracker because I bought something like this an year ago and quickly became dissapointed by the dubious quality of the hardware design and software of the product.

here is the first prototype - the magnet wire was used to debug the hardware flow control-enabled UART of the sim900.



the first assembled module is ready to be used on my trip to Greece. instead of a small flat LiPo I ended up using 2 cells from a discarded laptop battery - there was no time to wire this to my motorbike. now after ~20 days it is still tracking.



I am pretty happy with this first revision, but I'm working on the next one that will include a small serial fram chip. I decided to use that as a buffer because of the weird way the mobile phone company is counting the gprs traffic.

for some more eye-candy, you can see my route from home to Ouranoupoli on a google-map overlay here:
http://www.simplex.ro/files/trips/test.html
 
waypoints are 10 minutes apart, the trip took 10 hours and about 800km.

project home: https://github.com/rodan/tracy
 

 

here's my latest project, a fully open-source msp430f5510-based gps/gprs tracker. it's a device that wakes up every few minutes and does the following:

 - tries to get a gps fix
 - connects to the gsm network, marks the tower cell ids it talks to
 - executes sms commands received - if any
 - starts a gprs connection and sends all the info it has collected via http to my server

it does all this only based on interrupts (zero blocking functions are used - all the similar projects I've seen are riddled with delay()s).
functions that fail due to network unavailability are retried a given number of times.

the data received on the server is placed into a database and gps positions of the cell towers are obtained for future triangulation. this info can be used if there is no gps coverage due to obstacles.
 


to give a little context, I felt the need of making my own tracker because I bought something like this an year ago and quickly became dissapointed by the dubious quality of the hardware design and software of the product.

here is the first prototype - the magnet wire was used to debug the hardware flow control-enabled UART of the sim900.



the first assembled module is ready to be used on my trip to Greece. instead of a small flat LiPo I ended up using 2 cells from a discarded laptop battery - there was no time to wire this to my motorbike. now after ~20 days it is still tracking.



I am pretty happy with this first revision, but I'm working on the next one that will include a small serial fram chip. I decided to use that as a buffer because of the weird way the mobile phone company is counting the gprs traffic.

for some more eye-candy, you can see my route from home to Ouranoupoli on a google-map overlay here:
http://www.simplex.ro/files/trips/test.html
 
waypoints are 10 minutes apart, the trip took 10 hours and about 800km.

project home: https://github.com/rodan/tracy
 

 

here's my latest project, a fully open-source msp430f5510-based gps/gprs tracker. it's a device that wakes up every few minutes and does the following:

 - tries to get a gps fix
 - connects to the gsm network, marks the tower cell ids it talks to
 - executes sms commands received - if any
 - starts a gprs connection and sends all the info it has collected via http to my server

it does all this only based on interrupts (zero blocking functions are used - all the similar projects I've seen are riddled with delay()s).
functions that fail due to network unavailability are retried a given number of times.

the data received on the server is placed into a database and gps positions of the cell towers are obtained for future triangulation. this info can be used if there is no gps coverage due to obstacles.
 


to give a little context, I felt the need of making my own tracker because I bought something like this an year ago and quickly became dissapointed by the dubious quality of the hardware design and software of the product.

here is the first prototype - the magnet wire was used to debug the hardware flow control-enabled UART of the sim900.



the first assembled module is ready to be used on my trip to Greece. instead of a small flat LiPo I ended up using 2 cells from a discarded laptop battery - there was no time to wire this to my motorbike. now after ~20 days it is still tracking.



I am pretty happy with this first revision, but I'm working on the next one that will include a small serial fram chip. I decided to use that as a buffer because of the weird way the mobile phone company is counting the gprs traffic.

for some more eye-candy, you can see my route from home to Ouranoupoli on a google-map overlay here:
http://www.simplex.ro/files/trips/test.html
 
waypoints are 10 minutes apart, the trip took 10 hours and about 800km.

project home: https://github.com/rodan/tracy
 

 

here's my latest project, a fully open-source msp430f5510-based gps/gprs tracker. it's a device that wakes up every few minutes and does the following:

 - tries to get a gps fix
 - connects to the gsm network, marks the tower cell ids it talks to
 - executes sms commands received - if any
 - starts a gprs connection and sends all the info it has collected via http to my server

it does all this only based on interrupts (zero blocking functions are used - all the similar projects I've seen are riddled with delay()s).
functions that fail due to network unavailability are retried a given number of times.

the data received on the server is placed into a database and gps positions of the cell towers are obtained for future triangulation. this info can be used if there is no gps coverage due to obstacles.
 


to give a little context, I felt the need of making my own tracker because I bought something like this an year ago and quickly became dissapointed by the dubious quality of the hardware design and software of the product.

here is the first prototype - the magnet wire was used to debug the hardware flow control-enabled UART of the sim900.



the first assembled module is ready to be used on my trip to Greece. instead of a small flat LiPo I ended up using 2 cells from a discarded laptop battery - there was no time to wire this to my motorbike. now after ~20 days it is still tracking.



I am pretty happy with this first revision, but I'm working on the next one that will include a small serial fram chip. I decided to use that as a buffer because of the weird way the mobile phone company is counting the gprs traffic.

for some more eye-candy, you can see my route from home to Ouranoupoli on a google-map overlay here:
http://www.simplex.ro/files/trips/test.html
 
waypoints are 10 minutes apart, the trip took 10 hours and about 800km.

project home: https://github.com/rodan/tracy
 

 

here's my latest project, a fully open-source msp430f5510-based gps/gprs tracker. it's a device that wakes up every few minutes and does the following:

 - tries to get a gps fix
 - connects to the gsm network, marks the tower cell ids it talks to
 - executes sms commands received - if any
 - starts a gprs connection and sends all the info it has collected via http to my server

it does all this only based on interrupts (zero blocking functions are used - all the similar projects I've seen are riddled with delay()s).
functions that fail due to network unavailability are retried a given number of times.

the data received on the server is placed into a database and gps positions of the cell towers are obtained for future triangulation. this info can be used if there is no gps coverage due to obstacles.
 


to give a little context, I felt the need of making my own tracker because I bought something like this an year ago and quickly became dissapointed by the dubious quality of the hardware design and software of the product.

here is the first prototype - the magnet wire was used to debug the hardware flow control-enabled UART of the sim900.



the first assembled module is ready to be used on my trip to Greece. instead of a small flat LiPo I ended up using 2 cells from a discarded laptop battery - there was no time to wire this to my motorbike. now after ~20 days it is still tracking.



I am pretty happy with this first revision, but I'm working on the next one that will include a small serial fram chip. I decided to use that as a buffer because of the weird way the mobile phone company is counting the gprs traffic.

for some more eye-candy, you can see my route from home to Ouranoupoli on a google-map overlay here:
http://www.simplex.ro/files/trips/test.html
 
waypoints are 10 minutes apart, the trip took 10 hours and about 800km.

project home: https://github.com/rodan/tracy
 

 

here's my latest project, a fully open-source msp430f5510-based gps/gprs tracker. it's a device that wakes up every few minutes and does the following:

 - tries to get a gps fix
 - connects to the gsm network, marks the tower cell ids it talks to
 - executes sms commands received - if any
 - starts a gprs connection and sends all the info it has collected via http to my server

it does all this only based on interrupts (zero blocking functions are used - all the similar projects I've seen are riddled with delay()s).
functions that fail due to network unavailability are retried a given number of times.

the data received on the server is placed into a database and gps positions of the cell towers are obtained for future triangulation. this info can be used if there is no gps coverage due to obstacles.
 


to give a little context, I felt the need of making my own tracker because I bought something like this an year ago and quickly became dissapointed by the dubious quality of the hardware design and software of the product.

here is the first prototype - the magnet wire was used to debug the hardware flow control-enabled UART of the sim900.



the first assembled module is ready to be used on my trip to Greece. instead of a small flat LiPo I ended up using 2 cells from a discarded laptop battery - there was no time to wire this to my motorbike. now after ~20 days it is still tracking.



I am pretty happy with this first revision, but I'm working on the next one that will include a small serial fram chip. I decided to use that as a buffer because of the weird way the mobile phone company is counting the gprs traffic.

for some more eye-candy, you can see my route from home to Ouranoupoli on a google-map overlay here:
http://www.simplex.ro/files/trips/test.html
 
waypoints are 10 minutes apart, the trip took 10 hours and about 800km.

project home: https://github.com/rodan/tracy
 

 

here's my latest project, a fully open-source msp430f5510-based gps/gprs tracker. it's a device that wakes up every few minutes and does the following:

 - tries to get a gps fix
 - connects to the gsm network, marks the tower cell ids it talks to
 - executes sms commands received - if any
 - starts a gprs connection and sends all the info it has collected via http to my server

it does all this only based on interrupts (zero blocking functions are used - all the similar projects I've seen are riddled with delay()s).
functions that fail due to network unavailability are retried a given number of times.

the data received on the server is placed into a database and gps positions of the cell towers are obtained for future triangulation. this info can be used if there is no gps coverage due to obstacles.
 


to give a little context, I felt the need of making my own tracker because I bought something like this an year ago and quickly became dissapointed by the dubious quality of the hardware design and software of the product.

here is the first prototype - the magnet wire was used to debug the hardware flow control-enabled UART of the sim900.



the first assembled module is ready to be used on my trip to Greece. instead of a small flat LiPo I ended up using 2 cells from a discarded laptop battery - there was no time to wire this to my motorbike. now after ~20 days it is still tracking.



I am pretty happy with this first revision, but I'm working on the next one that will include a small serial fram chip. I decided to use that as a buffer because of the weird way the mobile phone company is counting the gprs traffic.

for some more eye-candy, you can see my route from home to Ouranoupoli on a google-map overlay here:
http://www.simplex.ro/files/trips/test.html
 
waypoints are 10 minutes apart, the trip took 10 hours and about 800km.

project home: https://github.com/rodan/tracy
 

 

Update #5 - panels!
 
@@bluehash thanks for the pointer to front panel express. they also have a partner in Germany so I did not have to pay extra taxes and expensive shipping for the same service.
 
last peek inside
 

 
and the finished product
 

 

 
everything is open source and available at https://github.com/rodan/ampy
more pictures available here
 
I will probably end up documenting the mixer board and eventually sell populated/tested copies it if anyone is interested.