Picaxe/Pi DataLogger

julianE

Senior Member
#1
Hello,
I'm at a planning stage for a remote data logger and have a question. The project will be a Raspberry Pi attached to the programming inputs of a Picaxe, 20M2 or 20X2. I will be using Pi UART ttyS0 connected through an inverter to Picaxe programming pins. That's all tested and working. On the Picaxe side I plan on recreating the AXE 110 type logger. The AXE110 uses separate pins for programming and data retrieval, I would like to use the programming pins to retrieve data. Just use SERTXD from the Picaxe and capture the data on the PI side and maybe have a message to signal the end of data. My plan is to use the SERRXD command to tell the Picaxe when to send the data but I'm not sure if it's the best option, my concern is that I might lock up the Picaxe and not be able to program it. I'm thinking if I'm careful I can use the disconnect command and the SERRXD timeout and run a tight loop. The other option I'm considering is to use a PI GPIO pin to trigger data sending from the Pi, maybe even use an interrupt or just run a tight loop. Is the SERRXD only option reliable enough or should I go with the additional complexity of a GPIO pin?

None of this is terribly critical, the Picaxe/Pi combination will be in the garage, only a 15 meter walk...but I'm a very lazy man :)

Thanks in advance.
 

techElder

Well-known member
#2
What is your purpose for singling out the "programming pins" of the PICAXE? Specifically, what pins are you calling the "programming pins"? If you are just going to set up a serial link between the PI and the PICAXE, I'm sure there are other pairs of pins that can be used in a 20 pin PICAXE.

If you are somehow thinking about changing the compiled program within the PICAXE, then that would be unique.
 
#3
…. my concern is that I might lock up the Picaxe and not be able to program it. I'm thinking if I'm careful I can use the disconnect command and the SERRXD timeout and run a tight loop.
A PICAXE will never truly "lock up" or "brick" itself, since you always have the hard reset option: when power up or reset, the PICAXE always checks the SerIn pin for a download before it executes the first line of your code.

Using Disconnect and SerRxd will work but you only need to execute Disconnect once unless you later execute a Reconnect command. But executing a Reconnect command is not very practical unless you set up some sort of handshaking with the serial data/command source. Without this handshaking, Murphy's law says that the serial data will arrive when the PICAXE is vulnerable to resetting.
 

hippy

Technical Support
Staff member
#4
.
My plan is to use the SERRXD command to tell the Picaxe when to send the data but I'm not sure if it's the best option, my concern is that I might lock up the Picaxe and not be able to program it. I'm thinking if I'm careful I can use the disconnect command and the SERRXD timeout and run a tight loop.
A tight loop should work and it should be possible to create a system which does what you want without locking up.
 

julianE

Senior Member
#5
A tight loop should work and it should be possible to create a system which does what you want without locking up.
Thanks everyone. I have had good success with SERRXD before so will stick with it.

Murphy's law says that the serial data will arrive when the PICAXE is vulnerable to resetting.
Murphy is always a concern. Thanks for your suggestions.

Soon I'll be having difficult questions of interfacing OpAmp output to the Picaxe, analog processing is very difficult for me, textbook analog circuits don't always mesh with real world circuits.
 

lbenson

Senior Member
#6
Neat idea to be able to reprogram the picaxe from the pi. You might want to be able to control power-cycling of the picaxe with one of the pi GPIO pins.

One question--what do you want to do with the picaxe that you can't do with the pi GPIOs? ADC comes to mind, and there are other things.

One other option for interfacing is i2c with an X2 slave--the pi has access to the first 128 bytes of the picaxe as if it were an eeprom.
 

julianE

Senior Member
#7
Neat idea to be able to reprogram the picaxe from the pi. You might want to be able to control power-cycling of the picaxe with one of the pi GPIO pins.

One question--what do you want to do with the picaxe that you can't do with the pi GPIOs? ADC comes to mind, and there are other things.

One other option for interfacing is i2c with an X2 slave--the pi has access to the first 128 bytes of the picaxe as if it were an eeprom.
Some of it is just habit, I'm comfortable and used to the picaxe. Also, this forum is the most helpful. Brilliant people are not overly rare, 1 out of 200 is a genius, what's rare is brilliant people willing to help. I am regularly astonished by the people on this forum, I received answers to my question within hours.

I can use an A to D converter chip with the Pi but it's so much easier to have the Picaxe collect the data in the background storing it in an external EEPROM and then sending the data to the Pi. This project will be sitting in the garage and will be powered from the wall. I also have projects that are solar powered and in that case I shutdown the Pi to conserve battery power, remotely turning the Pi on when needed using a picaxe with a radio module.

I have tried Pi i2c X2 slave option a few years back and it does work well.

I really like your remote work and the river cam. Some day I would like to set up an all sky camera at a remote rural location and have it controlled with a Pi/Picaxe combination
 

lbenson

Senior Member
#8
Thanks. Higher resolution rivercam here: http://lyzby.com/cam2.html

Uses this 3264X2448 camera module: 3264X2448

In searching for that link, I found this with the same resolution, but with zoom: zoom

That might make a good picaxe-able eagle cam, to zoom in and out from the tree they like to perch in.

And this, with fisheye lens: fisheye

So tell me about "all sky camera", please. I did a quick search and found pricy (~$1,000) waterproofed fisheye cameras with not particularly good resolution. That above-linked fisheye, if waterproofed, might be better.

I'm wondering if Milton, Nova Scotia might be a good place for an all-sky camera. I've never seen the Milky Way more clearly than from my back deck, but there are streetlights in front, and across the river behind trees a filling station whose night lighting contaminates the sky when it is overcast. (Of course, not much to see when overcast.) How does one properly enclose a sky-facing camera with moisture-shedding waterproofing?

I'm not exactly what you would call "rural"--it's a small village--but if you go out my across-the-street neighbor's back yard and walk west northwest, you could go for nearly 60 miles without hitting a paved road.
 
Last edited:

julianE

Senior Member
#9
How does one properly enclose a sky-facing camera with moisture-shedding waterproofing?
Here are a couple items for making an all sky camera,

Dome

Gasket

There might be a need for a heater to keep condensation down, I was considering just having a desiccant inside the dome.

The cameras you linked are excellent, great prices too, thanks. I've experimented with the Pi camera it uses a sony IMX219 sensor and it works well, you can do a time exposure with camera and that helps. The expensive dedicated astronomy cameras have larger pixels and lower resolution and better light gathering. I'm sure the ones you linked are at least 80% as good as the expensive ones. Like everything, you have to spend a lot of money to make small gains.

I'm sure you have seen images of large meteors streaking across the sky captured by dash cams. Dash cams use very inexpensive sensors so the ones you have found will do very well. My skies are drenched by light pollution but I can still see interesting things. In the summer I try to get outside every evening to spot the International Space Station streak across. I have friends with land away from cities and it would be cool to have a remote telescope there linked over internet. Yes, I'm sure there are many telescopes on line already and I could just use them but where is the poetry :). I do like that everything has become so easy but I miss the days when I used to spend hours outside trying to see all the Messier objects.
 

lbenson

Senior Member
#10
Thanks for that. "Better light gathering"--ah, so much I don't know. I've ordered the fisheye and zoom cameras. I'm not sure I can do much experimenting with "all sky" from where I am snowbirding in Florida--front is flooded with street light and back is obscured with tree canopy (no winter-time relief from tree canopy with trees that are live oaks).

I hadn't thought of time-lapse--that could be fun when the meteor showers continue so far past my bedtime, though we have spent half a night in sleeping bags on loungers on the back deck. (I'm afraid I dozed and missed much of what my wife saw.)
 

julianE

Senior Member
#11
BTW, I love the new river cam, much sharper, looks great. Florida, not a bad place to be this time of year :)

I have not seen the fancy astronomical cameras up close.
Here is a link to a site I like,
Allsky
and here is the camera used on that site,
ZWO camera

Just a little different sensor from the one you bought, a little larger with fewer pixels so each pixel is bigger thus better light gathering. Both Sony sensors. I think being mounted in a metal enclosure reduces thermal noise. Not much of an issue in frigid Canada.

Last time I enjoyed a meteor shower we drove about 70 miles away from the city lights, I got so cold that I could not stop shaking, barely got the key in the ignition my hands shook so much. I did see many meteors so it was worth it, many a time I've driven far and saw nothing due to clouds.
 

lbenson

Senior Member
#12
Again thanks for the links. That ZWO camera is beyond my price range as someone with a casual interest. If the fisheye I bought doesn't suit, I can find another use for it.

I've also driven far and gotten cold--sometimes to see lots of meteors, sometimes few.

The site you linked looks to have good information: "A Linux based server grabs individual images from the video server, integrates eight frames together per minute to help reduce image noise, and creates and stores the various time-lapse movies. The heavy lifting is done with mencoder, and the system is glued together with simple shell script cron jobs."

That's about within the scope of what I know how to do if I knew what was meant by "integrates eight frames together per minute".
Overlays? Averages pixel per pixel?
 

julianE

Senior Member
#13
That's about within the scope of what I know how to do if I knew what was meant by "integrates eight frames together per minute".
Overlays? Averages pixel per pixel?
My best guess about integration is that it's averaging but that's a wild guess. Probably unnecessary step.

The camera you got will work just fine, I've seen people using web cams for all sky cameras.
 

julianE

Senior Member
#14
I ran into an unexpected issue with my Pi/Picaxe combo, today temperatures plummeted to below 20 C, good time to check the robustness of modern electronics. I knew the picaxe would do just fine cause at least one of them took a ride in space. Surprisingly, the Pi shut down at 0 C. I was very surprised. From a little internet research the issue lies with the WiFi chips. So if you plan on programming a remote picaxe with a Pi you may not be able to access it through WiFi in the winter. The issue I had is with the Pi Zero Wireless. I only tried it with one sample of Pi so far from scientific.
 

Janne

Senior Member
#15
Hi, Are you using some sort of x86 emulator to program picaxe from the raspberry? I'd be interested to hear your solution as I could use a raspberry-programmable picaxe myself. Or do you mean just collecting data from the picaxe to the raspberry using the serial interface?
 

hippy

Technical Support
Staff member
#16
Are you using some sort of x86 emulator to program picaxe from the raspberry? I'd be interested to hear your solution as I could use a raspberry-programmable picaxe myself.
One can download programs to a PICAXE from a Pi thanks to the work done by forum member fanoush in getting the PICAXE x86 Linux compilers running through QEMU -

https://picaxeforum.co.uk/threads/arm-binaries-for-command-line-compilers.22547

Code:
cd ~
wget http://fanoush.wz.cz/picaxe/picaxe-raspberrypi.tar.gz
wget http://www.picaxe.com/downloads/picaxe.tgz
tar -zxvf picaxe-raspberrypi.tar.gz
tar -zxvf picaxe.tgz -C ./picaxe/i386/compilers
Code:
cd ~
cd picaxe
./bin/picaxe08m2 -h
 
Last edited:

julianE

Senior Member
#17
Hi, Are you using some sort of x86 emulator to program picaxe from the raspberry? I'd be interested to hear your solution as I could use a raspberry-programmable picaxe myself. Or do you mean just collecting data from the picaxe to the raspberry using the serial interface?
Hi Janne, exactly what Hippy says. Here is the information I used to get it working,

Picaxe/Pi

There are some slight changes, one I remember offhand is serial device name on the Pi changes depending on which image the Pi is using.

Once set up programming the picaxe with pi works very smoothly.
 

hippy

Technical Support
Staff member
#18
serial device name on the Pi changes depending on which image the Pi is using
That is correct and it also depends on which particular Pi board you have. There are two on-chip UART's; a full spec one and a more limited one known as a Mini-UART. Both should work with the PICAXE after signal polarity inversion. The full spec UART is /dev/ttyAMA0 and the Mini-UART is /dev/ttyS0.

On Pi's without Wi-Fi/Bluetooth /dev/ttyAMA0 is the one to use, but for boards with Wi-Fi/Bluetooth it is used for those and /dev/ttyS0 is the one to use.

To make things easier /dev/serial0 is also the name of the UART you have GPIO access to regardless of which board you have, /dev/serial1 is the other. So basically always use /dev/serial0 rather than anything else if connecting to GPIO UART pins. That's not strictly true but anything else gets even more complicated.

Note that all Pi GPIO signal pins, including UART pins, are 3V3 only. Don't directly connect a 5V powered PICAXE to those pins or that may cause damage to the Pi.

I would personally recommend using an AXE027 or other USB-to-RS232 interface as that avoids having to configure the Pi to use a UART, delivers the correct signal polarity for a PICAXE, avoids signal voltage issues, and will always be /dev/ttyUSB0 if only one such cable is used.
 
Last edited:

Janne

Senior Member
#19
Thanks for the info, I'll look into it.

A word of caution about using the UART on PI, at least on some PI 3 B boards with bluetooth by default the UART pins on the 40-pin IO header are being run by the software uart, and the baudrate will go haywire if the CPU goes into reduced speed mode. Not sure this has been fixed in a later update. It is possible to disable the BT and assign the hardware uart to the IO pins, which is what I did after I figured out the problem with the UART.
 

julianE

Senior Member
#20
A word of caution about using the UART on PI, at least on some PI 3 B boards with bluetooth by default the UART pins on the 40-pin IO header are being run by the software uart, and the baudrate will go haywire if the CPU goes into reduced speed mode.
Excellent point. I ran into that issue took a while to sort out.
 

hippy

Technical Support
Staff member
#21
A word of caution about using the UART on PI, at least on some PI 3 B boards with bluetooth by default the UART pins on the 40-pin IO header are being run by the software uart, and the baudrate will go haywire if the CPU goes into reduced speed mode.
Good point, and that can happen whenever using the Mini-UART, hence why more problematic on those with Wi-Fi/Bluetooth because that's what has to be used unless Bluetooth is disabled.

The Mini-UART is clocked from the system clock so, much like SERTXD, the baud rate changes as the system frequency does. Not sure why the chip was designed how it is, doesn't have both UART's running from independent clocks, or why the Wi-Fi/Bluetooth combo chip uses two separate interfaces, but that's the way it is.
 

lbenson

Senior Member
#23
Yes, I bought both cameras. I have only tested that they work--haven't set up the "all-sky" fisheye or figured out how (with a picaxe) to rotate the two rings on the zoom camera for zoom and focus, but both look good. Where I am, I don't have an optimal place to put the all-sky, but I do plan to try it here in Florida before it gets to its real home in Nova Scotia.
 
Last edited:
Top