Running on 3V logic about wwvb HOT 27 CLOSED

Hi,

Sorry for the delay.

It is most likely the PWM_LOW value which was set to be - 17dB below 5V. Try settling it to zero after you initialise wwvb_tx using wwvb_tx.setup() in arduino setup(). The command is :
wwvb_tx.setPWM_LOW(0);

Try this first!

Regarding the led circuit - its not really needed. You could scrap the resistor and capacitor and instead inline the led with your antenna (the led acts as a current limiter for your antenna).
Ie wwvb out -> antenna -> +led- -> gnd.
You won't damage the led by driving it directly as arduino pins are limited to 20mA, but you may want a current limiting resistor between the antenna and the led, say 1k or less, depending on how bright you like that led pulsing.

FYI The 110R and 1uF form a lowpass RC filter at 1.447kHz. It's just there to filter the 60kHz carrier from the roughly 1Hz to 3Hz (max 10Hz I would think) modulation pulse. For a 1uF capacitor the resistor value could be anywhere between 5R (32kHz cut off) and 1k ohm (159Hz). In your setup (if you don't change the layout as i mentioned above) you normally want to minimise the current through the rc circuit so the antenna loop has more available current / more transmit power. V=I*R so you want a higher value resistor in the RC circuit - closer to 1k.

from wwvb.

Hi Mark,
I tried your suggestion.

Pin 9 --> Antenna --> +LED- --> GND

Placed the LED in-line with the antenna coil and made a call to setPWM_LOW(0).
The code was already there in the sketch in comments so I uncommented it.

Tried again and saw that in the WWVB signal, the highs were still bright on the LED and the lows were completely dark (no light from LED), so I believe that this was good. In the past the LED would continue to stay dimly lit amid the dots and dashes. So now it looks a lot better.

The thing still doesn't work though. It's not syncing up my desk clock.

Going back to the Arduino micro, I noticed that the dots and dashes were a bit shorter, and also the "unsupported NMEA sentences" error messages would come fast and furious on the serial monitor.

On the ATMega32U4 Feather, all of those things happen at a slower pace. So maybe it's a timing issue.

I did a bit more research and found that Arduino Micro functions at a 16MHz clock speed
https://www.adafruit.com/products/1086#technical-details-anchor

whereas the 32U4 feather works at an 8MHz clock speed!
https://www.adafruit.com/product/2771

Maybe that's contributing to my problem?

Is there anything I can modify in the code for the timing to adjust to an 8MHz clock speed processor?

Thanks in advance.

from wwvb.

My code checks F_CPU and is setup to work with either 8MHz or 16MHz. Its possible i missed something, but first try uploading the arduino blink example to your feather.

If it doesnt blink at the correct rate (1s on, 1s off?) you are selecting the wrong board option when you upload to the feather. As you said, its a 32u4 so any board with that chip (the micro for instance) and an 8mhz option should work.

from wwvb.

Hello Mark,
Sorry for the delay. There's no urgency at all to resolve this. It's a toy project of mine and I'm trying to miniaturize it only, so it takes less space on my desk. So respond whenever you have time, no need for any special urgency to this. And thanks for any help you can give me, as always.

I tried the blink sketch and the Pin 13 LED is giving me the correct pulse rate ( 1s on / 1s off ).

Additionally, during the build (I have verbose build output enabled),
I'm seeing that the "-DF_CPU=8000000UL" flag is being issued to the compiler.

I also tried adding this line, just to be sure:
#define F_CPU 8000000UL

The thing still pulses at a slower rate than the Arduino Micro.

I just received a multimeter yesterday

https://www.adafruit.com/product/850

I'm going to try and see if I can gauge the carrier frequency to find out whether I'm getting 60KHz or whether that is also off.

Thanks

from wwvb.

Okay, ill try and replicate it locally then.
A multimeter is always a good piece of kit to have, i have a knock off of that exact one (looks the same, but it's obviously different) you have which i keep in my bag - its remarkably accurate!
Im just not sure its usefull in this instance - i stand corrected :) neither of my multimeters measure frequency - time for me to upgrade!

The best thing I ever bought is a saleae logic (analyser) clone, this is what i use to check timing. You can use it to decode all sorts of signal types, and the software is excellent (the windows saleae software is much better than then Linux os pulseview).

This looks like the one I got $6.41 incl shipping to AUS
new 1sets New Arrival USB Logic Analyze 24M 8CH, MCU ARM FPGA DSP debug tool
http://s.aliexpress.com/ZV3eAN7v

from wwvb.

Hi Mark,
I just checked both transmitters antennae with the multimeter and I'm seeing a 60KHz carrier frequency for both.

So I think only the duration of the pulses is a bit off on the feather. The carrier frequency seems to be correct.

The multimeter seems to have an easier time in getting the 60KHz reading from the feather because the pulses are of a longer duration than the micro (of course this causes it to not sync the clock properly, which is the main issue).

Thanks.

from wwvb.

Good news!
I managed to scrounge up a 8MHz 32u4 so ill test it today. I'll also have a quick look at the isr as that's where the error would be.
Cheers

from wwvb.

Problem : the interrupt is taking too damn long at 8MHz and we are missing some. I expected as much.

Workaround :
Immediately following wwvb_tx.setup(); add the following code to set pulse widths to 2/3 of their expected size:
wwvb_tx.set(8081, 20202, 32323, 40404);

FYI - I found that pulse widths were exactly 1.5x their expected value, hence the 2/3 hack.

Bugfix:
This can be compensated in an update to the library, but im moving to another library so i might just put this in as a static hack (if it works) rather than fixing the real issue and rewriting the isr.

from wwvb.

Hello Mark,
I did as you advised and added the line right below the setup() call. This happened to be immediately before the setPWM_LOW() call.

It looks like this adjustment helped out the timing considerably.

Since I now have two parallel implementations of the same project, one with the Arduino micro and the other with the Adafruit 32u4 feather, I'm able to run them both at the same time and compare the behavior between the working and the nonworking device.

After making the adjustments you recommended, I noticed that both devices gather the data from the GPS module at the top of every 10 minutes (as you already are aware), after which they both commence their respective WWVB broadcasts at the same instant in time. I noticed that they both start out pulsing the same patterns and mirroring each other quite closely (timing wise). But after about half a minute the feather starts to lag behind the micro in it's pulsations. I haven't quite figured out yet whether the pulse lengths or the durations between pulses are off.

Do I have liberty to tweak these numbers in the set() call? And if so, what do these numbers represent? I tried to look at the header file but wasn't able to figure it out.

I believe we are very very close to getting it to work, but as of yet, my desk clock still doesn't sync up with the GPS time broadcasted by the feather implementation.

from wwvb.

The interrupt routine happens at 60kHz, and inside the routine is a counter that is used to set the modulated pulse width of the signal.

The numbers represent 20%, 50%, 80%, 100%.

You might just need to tweak the calibrate bit to fix it. If tge feather is lagging, set a negative value. If it is leading set a positive value.

Sorry, there isnt an easy way to calibrate it. I changed by a known value and checked the difference in the pulse timing using the saleae logic. You will need to do trial and error

from wwvb.

Hi Mark.
I tried to play around with the values a bit. I rounded the 100% counter down to 40,000 and adjusted the rest of the values down accordingly.

Seems the pulse rate is pretty close but the sync is still not happening.

I think I will invest in an oscilloscope. There's a portable one that is available for close to $100. It's not cheap but as far as prices go for conversational oscilloscopes, usually $300-$400, it's pretty reasonable and might get the job done for me here.

I'll probably order it mid next week and wait for the shipment to California all the way from New York (may take up to a week)

So let me spend some time with this on my own and I'll report back to you when I've resolved it.

If you want to close this issue, please feel free.

Thanks

from wwvb.

Put 'saleae logic analyzer' into Ebay and have a look. $20 gets you something that will examine the 60khz waveform in detail. Cheers.

from wwvb.

I agree with sneezy. The saleae is great, you can do several minutes of capture and analyse the whole stream. Download the software and have a play - they have a simulated capture to analyse.

For my own interest, what dso where you looking at? I use a dso quad - they are awesome, although it looks like they are becoming end of line. The seeed studio dso touch is now only $99, a good buy but only 2 channels.

from wwvb.

Hi,
I took Sneezy's advice and ordered the following logic analyzer.

http://m.ebay.com/itm/201541710029?_trksid=p2060353.m2749.l2649&_mwBanner=1

It's sold by alice (which happens to be Julian Ilett's favorite seller, he's always showing off items he bought from Alice in his YouTube videos).

The portable oscillator I was thinking of getting was the following.

https://www.adafruit.com/product/468

I think I'll pass on it for the time being. If I can avoid spending a hundred bucks and manage to get the job done for way cheaper, I'm a happy camper.

from wwvb.

They are a great tool. I use mine mostly for serial data capture and analysis. The software will convert the sequence to Hex or ASCII if you tell it that's what it should be etc. Great to reverse engineer any serial comms between two devices serial chatting. I use it for OBDII and car ECU projects like that. Will do what you want easily.

from wwvb.

Here's an example of the saleae software from my pwm library

from wwvb.

Just a quick update - ive fixed it for me, i just need time to comment it and upload it (gimme a few days)

I've always been concerned about the amount of time taken in calculations in the isr, and this is the reason it doesn't work for an 8MHz arduino.

Im currently working on a new wwvb & jjy library that uses a second timer to set pulse widths, but this is not the approach i took in my bug fix/hack.

In short, im using checks to millis() in loop() to maintain this timing. The overhead involved adds about 50ms of positive drift in 60s so 1s in 20 mins of drift. This is 'accurate enough' for @mr-sneezy BALDR desk clock, so success!

Note that the drift I'm talking about should be compensated out by the gps sync/wwvb transmit 10 min cycle.

from wwvb.

Hi Mark.
I'll be on the lookout for your updates to the library.

Meanwhile I'm still waiting for the saleae logic analyzer to get here from Alice. It's taking forever.

I did order a 60KHz receiver module from ebay seller from Canada.

http://www.ebay.com/itm/262655492972

With this module I was able to construct a make-shift wwvb listener. I used an Arduino Micro which runs a simple forever loop which continuously reads pin5 and writes that value to pin13 and no delays built into the loop.

So instantaneously I can see the received pulses on the on-board LED attached to pin13. And to make it a little more annoying for my family, I also attached a loud piezo buzzer to the same pin13, so I can see as well as hear the pulses.

Seems the carrier frequency coming out of the Feather 32u4 is correct.

I got an idea just now to take this listener device a step further: record the millis() value on a rising edge and subtract it from the millis() on the falling edge, and spit that out on the serial monitor.

This will let me see exactly the with of each pulse.

I think it won't be much coding to accomplish that so I'll try that in a day or two.

Once I get that working, I'll go back to the feather and tweak the values there until I see the correct pulse widths: 200ms, 500ms, 800ms, and 1000ms

I'll let you know once I get all of this done.

Thanks

from wwvb.

Ive been meaning to buy one of those, but couldnt find a seller that ships to au.

Ive got that exact functionality integrated with my wwvb library as a decoder that i use in a year setup. Ill upload that too, but in short - check out the arduino function pulseIn()

from wwvb.

@pepsiplease69 check out the following for inspiration regarding your receiver. Its my new (tx is not-working) wwvb library wwvb_jjy_rx

I've updated the wwvb library and added an example for the 8MHz that does not time sync atmega32u4_8MHz

I need to modify the existing examples, and then remove this example, but the crux are the #define guards which allow the 60kHz isr for 16MHz, and move the isr (pulse timing) calls to loop()

from wwvb.

So I'm working on the wwvb_jjy library and i realise I've made the same dumb mistake in that one regarding the isr.

Im using my pwm library, which is awesome, then I realise I need to expose the timer compare register as well as the timer overflow register. Simple enough for a hack, but now the api is clunky and confusing. Long story short - I've re written huge sections of it, breaking changes but it's easier to maintain.

In short - thanks for finding the bug, its made two other libraries much better and thrown fuel on my hate fire for avr's inconsistent api 🔥

from wwvb.

Hi Mark.
That sounds great. Let me know when you've uploaded the the new library and I can try it out.

from wwvb.

@pepsiplease69 - please try the library, i just updated it :)

Also, the wwvb_jjy repository is now up and running so i will be abandoning this to work on the new library (no gps time synced examples there yet though)

from wwvb.

Okay, ive tested https://github.com/micooke/WWVB/blob/master/examples/atmega32u4_8MHz/atmega32u4_8MHz.ino and its working.

The new wwvb_jjy library should also work now that i have the 16MHz working.

from wwvb.

Hi Mark,
Good news!
The wwvb_jjy library works!

I compiled and ran the wwvb_jjy_tx example sketch and I didn't have to do anything to the hardware, pin 9 was already my antenna pin.

By default it broadcasts a date of Feb 2, 2005 and I started seeing that on my desk clock after it received the signal.

Right above, I could specify the __DATE__ and the __TIME__ pre-processor directives for setting the time, so I tried that next, and it again synced and showed today's date May 5 on the desk clock.

Now I will try to integrate the on-board GPS receiver to get the time from there and broadcast it over WWVB.

Awesome help mate, thanks for all your efforts.

from wwvb.

from wwvb.

I haven't tested it yet, but try https://github.com/micooke/wwvb_jjy/blob/master/examples/TinyGPS_WWVB_tx/TinyGPS_WWVB_tx.ino

You will need to modify it for your pinout on line 33, and make any adjustments to timezone but it *should work.

Requires the TinyGPS library https://github.com/mikalhart/TinyGPS

from wwvb.