First the bad news. In my last post detailing how to build your own Davis console datalogger, I speculated that using a bigger memory chip than what Davis used in their original design might get picked up by the console and allow more archive records to be stored. Unfortunately that is not the case. The Davis 1 Mbit version tops out at 2560 records. So does my 4 Mbit version. If you are going to build your own (more on this in a second), save the 43 cents and stick with the 1 Mbit chip.
The Bane of the "Off by one" Programming Error
Now the good news. When I got my DIY logger working a couple weeks back, I made a wxforum post detailing what I had found. I made a similar post when I figured out how to build your own computer interface to the console, and comments poured in quickly. This time around, it was a little different...
Kinda Quiet Around Here...
But little did I realize that despite the initial, deafening silence, great things were at work: wxforum member belfryboy put his head down and got busy. After an iteration or two, behold!
A Schematic!
Yes indeed. He did what I should have done and put together a schematic in Eagle. This has a connection for both the Atmel flash chip for datalogging and a six pin connector for hooking up something like the Sparkfun FTDI cable. These two pieces give you the complete equivalent of the Davis USB logger (except that this version will maintain a reliable connection). Now, behold again!
A PCB Layout!
This is the corresponding board layout for the schematic above. The ground pour isn't shown for clarity, and so you can see the shout-out that belfryboy gave me on the bottom layer. This board is single sided and therefore DIY friendly. Speaking of DIY friendly, the design can be easily pulled into the freeware version of CADSoft Eagle so that anybody can have a look and play around with this. All you need to do is grab the design files from here and you are good to go. And if you don't have the means to build your own circuit boards, belfryboy will build one up for you.
If you do build this, remember from my last post that you need to use a terminal program to actually activate the logging function in the console since Cumulus doesn't do this automatically. I think I'll ping the author to
see if he'd be kind enough to add this function. belfryboy has a setup utility in the works and I'll add it to the design files once I get it.
So what the heck are you waiting for? Get out there and build something. Anything. Figure something out. Learn something new. The reward is the journey. Remember: You Can't, You Won't, And You Don't Stop.
Dear Belfryboy, I have a problem: My Davis Vantage Pro2 has an Expansion Connector with 1.27mm pitch! Your board layout seems to use a connector with 1.35mm or more. Please let me know if you can build for me an equivalent of your VP_logger with 1.27mm pitch - connector. With my best regards Peter Marschat (aon.912212253@aon.at)
The setup utility is a .Net application and would not run on Linux. It works despite throwing up a scary looking error message first. Much simpler and easier just to send the one command you need through a terminal.
Don't know about wxview, but I'd be surprised if it doesn't work.
I have everything working (over Xbee even) except for the logger.
I've triple checked all of the connections and sent the appropriate SETPER 1 and START commands. Cumulus can't read it correctly, so I dropped back to the Perl package that you referenced in a different post.
It reads the data, but it is all essentially random. However, it looks like the CRCs are all correct though, so something odd is happening. On second thought, those are probably generated for the serial communication and not stored in the flash.
I have a decoupling cap on the power, but I suspect that my cable is too long. I made the cable about 18 inches. And now I can't find my spare connector to shorten it.
Is that a plausible culprit? Can I do anything to clean the data besides shortening the cable?
Thanks for all of your hard work on this, and sorry to bug you with a stupid question.
18" isn't very long for I2C communications. I don't suppose you have a scope to look at this? Your cable is unlikely to be the problem but anything is possible. If this is indeed it, you might be able to clean things up by adding a pullup resistor: http://dsscircuits.com/articles/effects-of-varying-i2c-pull-up-resistors.html
I never bothered with a decoupling cap, BTW. I considered this circuit too slow to need one.
It really sounds to me like a wiring problem: miswiring, short, or open. Are you using pin 1 as the bottom right of the connector as viewed from the back?
I was trying to debug the SPI with my Bus Pirate, but not getting far. The very odd thing is that the SCK trace and the SI one look very similar in the traces I got out.
I'd have expected the clock signal to be more regular. So it adds credence to the messed up wiring hypothesis. That, or I fried the chip (ESD when handling or heat when soldering).
As a note, it is SPI not I2C... right? And do you have any idea what frequency the bus is driven at? I'm trying to work out what speed to set my capture at.
So... I fired up the scope. I'm not seeing anything much on the clock signal. The signal gets noisy, but never goes low in any meaningful sense. I'd have expected to see something approximating a square wave, but I don't see anything like it.
Is the problem that I am trying to debug it in place? Do I need to pull the chip to see the signals?
Any suggestions would be greatly appreciated (or please feel free to point me to a better forum).
Okay. I finally found the clock signal. It was much faster than I expected. I think it is about 500 khz (based on the blurry trace from my poor old scope). So, much faster than the Bus Pirate can tolerate.
However the clock signal looked fairly clean, there was a nasty overshoot on the leading edge of the square wave, so it is conceivable that confuses the SPI bus. But I'm not sure.
@Ben: Yes, it is SPI and not I2C. I confuse the two all the time.
I might be able to hook up to my setup sometime this weekend and see if I can catch a few snapshots of the SPI bus activity when talking to the memory chip. And you said you see a clock, but do you see any data either way? If the clock doesn't look like it never goes low "in any meaningful sense" then you might not have your grounds connected up.
You should certainly be able to see activity on the SPI bus with the memory chip connected. But you could also take the memory chip off and still see data: the SPI bus is also how the CPU talks to the radio chip inside the console. See here.
I'm sure you have some kind of wiring problem to the memory chip. If the SPI bus itself wasn't working, the RF chip wouldn't be working and the console wouldn't be able to pick up the ISS.
I found a way to get bus activity for a prolonged period, so I managed to find the clock and bus activity. I was digging in completely the wrong place frequency-wise before (because the signals were so brief I was missing them).
Anwyay, I found the clock signal and found the SO and SI data. Things look correct-ish, except for the overshoot on the rising signal. My hunch is that the spike is messing with the SPI bus triggering. But that's just a hunch based on nothing much.
Unfortunately I think I need to correlate the clock and the bus signals to debug that. Or work out a way to clean the square waves. I tried a .01 microfarad cap, but that rounded it too much and stopped me from getting any data from the chip (normally, I can read from it, but I read garbage).
To get around the memory limitation could you program an attiny to emulate the I2C communication of the memory chip and then the attiny would turn around and write the data to a bigger memory chip.
Dekay,
ReplyDeleteI now have a setup utility, nice and easy to use so that you don't have to hand crank through a terminal window!
Belfryboy
Dear Belfryboy, I have a problem:
DeleteMy Davis Vantage Pro2 has an Expansion Connector
with 1.27mm pitch! Your board layout seems to use
a connector with 1.35mm or more. Please let me know
if you can build for me an equivalent of your VP_logger
with 1.27mm pitch - connector.
With my best regards
Peter Marschat (aon.912212253@aon.at)
Belfryboy, I just checked by email and wxforum PM's and nothing so far. I'll update the blog once I get it.
ReplyDeleteDid the setup utility work?
ReplyDeleteDoes this all work with wxview in Linux?
Thanks!
The setup utility is a .Net application and would not run on Linux. It works despite throwing up a scary looking error message first. Much simpler and easier just to send the one command you need through a terminal.
ReplyDeleteDon't know about wxview, but I'd be surprised if it doesn't work.
Tarnation!
ReplyDeleteI have everything working (over Xbee even) except for the logger.
I've triple checked all of the connections and sent the appropriate SETPER 1 and START commands. Cumulus can't read it correctly, so I dropped back to the Perl package that you referenced in a different post.
It reads the data, but it is all essentially random. However, it looks like the CRCs are all correct though, so something odd is happening. On second thought, those are probably generated for the serial communication and not stored in the flash.
I have a decoupling cap on the power, but I suspect that my cable is too long. I made the cable about 18 inches. And now I can't find my spare connector to shorten it.
Is that a plausible culprit? Can I do anything to clean the data besides shortening the cable?
Thanks for all of your hard work on this, and sorry to bug you with a stupid question.
18" isn't very long for I2C communications. I don't suppose you have a scope to look at this? Your cable is unlikely to be the problem but anything is possible. If this is indeed it, you might be able to clean things up by adding a pullup resistor: http://dsscircuits.com/articles/effects-of-varying-i2c-pull-up-resistors.html
ReplyDeleteI never bothered with a decoupling cap, BTW. I considered this circuit too slow to need one.
It really sounds to me like a wiring problem: miswiring, short, or open. Are you using pin 1 as the bottom right of the connector as viewed from the back?
I have an old scope. I'll hook it up to see. I also have a bus pirate, so I'll see if I can use it as a logic analyzer for the I2C.
ReplyDeleteI'm fairly certain that I have the right pins, but I'll re-check everything. And I'll check again for shorts.
I have an old scope, I'll see what I can find.
ReplyDeleteI also have Bus Pirate, so I'll try using that as a logic analyzer for the I2C.
I'm pretty sure everything is wired up correctly. But I'll re-check everything and have another look for bad soldering.
Thanks for the help.
I have a very old scope that I'll hook up later.
ReplyDeleteI was trying to debug the SPI with my Bus Pirate, but not getting far. The very odd thing is that the SCK trace and the SI one look very similar in the traces I got out.
I'd have expected the clock signal to be more regular. So it adds credence to the messed up wiring hypothesis. That, or I fried the chip (ESD when handling or heat when soldering).
As a note, it is SPI not I2C... right? And do you have any idea what frequency the bus is driven at? I'm trying to work out what speed to set my capture at.
Thanks!
So... I fired up the scope. I'm not seeing anything much on the clock signal. The signal gets noisy, but never goes low in any meaningful sense. I'd have expected to see something approximating a square wave, but I don't see anything like it.
ReplyDeleteIs the problem that I am trying to debug it in place? Do I need to pull the chip to see the signals?
Any suggestions would be greatly appreciated (or please feel free to point me to a better forum).
Thanks again.
Okay. I finally found the clock signal. It was much faster than I expected. I think it is about 500 khz (based on the blurry trace from my poor old scope). So, much faster than the Bus Pirate can tolerate.
ReplyDeleteHowever the clock signal looked fairly clean, there was a nasty overshoot on the leading edge of the square wave, so it is conceivable that confuses the SPI bus. But I'm not sure.
@Ben: Yes, it is SPI and not I2C. I confuse the two all the time.
ReplyDeleteI might be able to hook up to my setup sometime this weekend and see if I can catch a few snapshots of the SPI bus activity when talking to the memory chip. And you said you see a clock, but do you see any data either way? If the clock doesn't look like it never goes low "in any meaningful sense" then you might not have your grounds connected up.
You should certainly be able to see activity on the SPI bus with the memory chip connected. But you could also take the memory chip off and still see data: the SPI bus is also how the CPU talks to the radio chip inside the console. See here.
I'm sure you have some kind of wiring problem to the memory chip. If the SPI bus itself wasn't working, the RF chip wouldn't be working and the console wouldn't be able to pick up the ISS.
I found a way to get bus activity for a prolonged period, so I managed to find the clock and bus activity. I was digging in completely the wrong place frequency-wise before (because the signals were so brief I was missing them).
ReplyDeleteAnwyay, I found the clock signal and found the SO and SI data. Things look correct-ish, except for the overshoot on the rising signal. My hunch is that the spike is messing with the SPI bus triggering. But that's just a hunch based on nothing much.
Unfortunately I think I need to correlate the clock and the bus signals to debug that. Or work out a way to clean the square waves. I tried a .01 microfarad cap, but that rounded it too much and stopped me from getting any data from the chip (normally, I can read from it, but I read garbage).
If you are reading garbage, maybe the problem is that you aren't writing it properly in the first place. Check the Write Protect pin is pulled high.
ReplyDeleteTo get around the memory limitation could you program an attiny to emulate the I2C communication of the memory chip and then the attiny would turn around and write the data to a bigger memory chip.
ReplyDelete