Yet another DIY GPSDO - yes, another one

[instantcrow]

it's a baud rate discrepancy. I'll figure it out.

[AndrewBCN]

it's a baud rate discrepancy. I'll figure it out.

You are right, and it's my fault, my apologies.     

In the GPSDO main program, please change:

Code: [Select]

#define BT_BAUD 57600
to

Code: [Select]

#define BT_BAUD 115200
recompile, redownload to the Black Pill.

That (in principle) should make it work. 

[instantcrow]

K. Will try that, however, with the HC-06 config.ino file, I can change name, but I can't check version or change baud rate to 115200. I'm pretty sure I'm commenting/uncommenting code correctly.

[instantcrow]

I'm nearly certain the AT commands AT+VERSION and AT+BAUD are not working with this particular HC-06 module (OSEPP BTM 01). AT+NAME worked on several occasions. I've tried different delay times for response, different BAUD setup rates, different V to module (both 3.3 and 5V). I was able to connect to and receive non-sense characters (due to Baud discrepancy), but now can't receive anything. I've never received responses for AT+BAUD or AT+VERSION, just "OK" with AT+NAME; was able to change name several times.

[AndrewBCN]

I'm nearly certain the AT commands AT+VERSION and AT+BAUD are not working with this particular HC-06 module (OSEPP BTM 01). AT+NAME worked on several occasions. I've tried different delay times for response, different BAUD setup rates, different V to module (both 3.3 and 5V). I was able to connect to and receive non-sense characters (due to Baud discrepancy), but now can't receive anything. I've never received responses for AT+BAUD or AT+VERSION, just "OK" with AT+NAME; was able to change name several times.

Now we are getting somewhere.

AT+VERSION also is not working with the HC-06 modules I have here, and AT+BAUD is not going to give you a "Response=..." message exactly because it changes the baudrate of the HC-06 module, so you would need to also change the baudrate of the STM32 MCU UART "on the fly", and the short program I wrote doesn't do that.

Keep trying, at some point you'll manage to match the baudrate of the HC-06 module with that of the UART of the STM32 MCU.

[iannez]

Good morning everyone!

I inserted a couple of new code lines that I think can improve data collection about the number of counts in circular buffers.

In practice, the circular buffers at 1000 and 10000 objects will be enabled to store data only after the previous buffer is full.

This serves to store data that had at least some corrections (at least 2 in the case of the 1000 buffer, 429s overflow).

So making the new data have a better deviation from the basic frequency (10MHz) and therefore during the average they will give a more precise result.

This should help you arrive first at the frequency lock.

Code: [Select]


// 1000 seconds buffer
if(cbHun_full)      <= NEW IF ADDED WITH WITH ANNEXED PARENTHESIS
  { 
    circbuf_tho64[cbitho_newest]=fcount64;
    cbitho_newest++;
    if (cbitho_newest > 1000) {
       cbTho_full=true; // this only needs to happen once, when the buffer fills up for the first time
       cbitho_newest = 0;   // (wrap around)
       cbTho_count++;
    }
  }

  // 10000 seconds buffer (2 hr 46 min 40 sec)
  if(cbTho_full)     <= NEW IF ADDED WITH WITH ANNEXED PARENTHESIS
  {
    circbuf_tth64[cbitth_newest]=fcount64;
    cbitth_newest++;
    if (cbitth_newest > 10000) {
       cbTth_full=true; // this only needs to happen once, when the buffer fills up for the first time
       cbitth_newest = 0;   // (wrap around)
       cbTth_count++;
    }
  }



AndrewBNC let me know what you think and if it can be useful 

See you soon, A.

[AndrewBCN]

Good morning everyone!

I inserted a couple of new code lines that I think can improve data collection about the number of counts in circular buffers.

In practice, the circular buffers at 1000 and 10000 objects will be enabled to store data only after the previous buffer is full.

This serves to store data that had at least some corrections (at least 2 in the case of the 1000 buffer, 429s overflow).

So making the new data have a better deviation from the basic frequency (10MHz) and therefore during the average they will give a more precise result.

This should help you arrive first at the frequency lock.
...
AndrewBNC let me know what you think and if it can be useful 

See you soon, A.

Thank you Angelo.
I think it's a very good idea.  Let me test it for a few days and if the results are confirmed good, I'll certainly add it to the next release on GitHub.

[instantcrow]

Now we are getting somewhere.

AT+VERSION also is not working with the HC-06 modules I have here, and AT+BAUD is not going to give you a "Response=..." message exactly because it changes the baudrate of the HC-06 module, so you would need to also change the baudrate of the STM32 MCU UART "on the fly", and the short program I wrote doesn't do that.

Keep trying, at some point you'll manage to match the baud rate of the HC-06 module with that of the UART of the STM32 MCU.

I can change the name every time at HC-06 BAUD 9600; however any attempt to change to any BAUD other than 9600 simply doesn't work. Iterative tests to change name following BAUD rate change don't work, only

Code: [Select]

Serial2.begin(9600);  // serial to Bluetooth moduleworks to change name.

Truly stumped on the HC-06...I'll cease and desist on this forum re: Hc-06, don't want to pollute it as it's really about this fantastic GPSDO.
-Instant (at baud of 9600)

[AndrewBCN]

Hi,

Here is the datasheet for the HC-06 module (attached).

Check Section 9．AT command set

There are two commands to try, depending on how you have set the UART speed in the main GPSDO program:

AT+BAUD7 <-------- (to set 57600 baudrate)

AT+BAUD8 <-------- (to set 115200 baudrate)

If both of these fail, you can try leaving the baudrate of the HC-06 module untouched, and change the speed of the STM32 MCU UART to 9600 baudrate:

Find this line in the main program:

Code: [Select]

#define BT_BAUD 57600
And replace with:

Code: [Select]

#define BT_BAUD 9600
but that is really a last resort solution, as at 9600 baud the Bluetooth interface doesn't quite have enough bandwidth for our rather verbose GPSDO output.

[instantcrow]

BT_BAUD 9600 worked. But it is same as GPS BAUD, and these conflict thereby preventing a GPS fix. I guess I could change the GPS module BAUD but that opens another can of worms.

For whatever reason, this HC-06 only registers the AT+NAME command. doesn't even respond to AT. I've reviewed other forums and the datasheet. definitely a sticky wicket here.

I know AT+BAUD8 was sent from STM32 to HC-06 as the AT+BAUD8 message showed up in my smartphone serial monitor. but just passed through.

[instantcrow]

There appears to be a key pin that needs to go high for AT commands...I'll test it out and report back

[AndrewBCN]

...
I know AT+BAUD8 was sent from STM32 to HC-06 as the AT+BAUD8 message showed up in my smartphone serial monitor. but just passed through.

OK, so it seems your module is simply not responding to the AT+BAUD8 command. Strange. I really don't know what to say to help you at this stage. I am stumped. 

[iannez]

Good evening everyone,

Andrewbnc a curiosity ...

Why in the calibration routine uses 3.2 in the calculation to follow?

Code: [Select]

   // for 16-bit PWM
   // 1.5V for PWM = 65536 X (1.5 / 3.2) = 30720 Results in Frequency F1 = 10MHz + E1
   // 2.5V for PWM = 65536 X (2.5 / 3.2) = 51200 Results in Frequency F2 = 10MHZ + E2

Wouldn't it be more precise 3.3 or the VDD value?

I have for Vdd a 3.31v now.

thanks, A.

[AndrewBCN]

Good evening everyone,

Andrewbnc a curiosity ...

Why in the calibration routine uses 3.2 in the calculation to follow?

Code: [Select]

   // for 16-bit PWM
   // 1.5V for PWM = 65536 X (1.5 / 3.2) = 30720 Results in Frequency F1 = 10MHz + E1
   // 2.5V for PWM = 65536 X (2.5 / 3.2) = 51200 Results in Frequency F2 = 10MHZ + E2

Wouldn't it be more precise 3.3 or the VDD value?

I have for Vdd a 3.31v now.

thanks, A.

That's a good question and the simple answer is that in this equation 3.1, 3.2 or 3.3 is not a critical value. But yes, you can try 3.3 or 3.31. 

[instantcrow]

OK, so it seems your module is simply not responding to the AT+BAUD8 command. Strange. I really don't know what to say to help you at this stage. I am stumped. 
[/quote]

Using a USB/TTL converter, I was able to send AT, AT+VERSION, AT+NAME and AT+BAUD8 to the same HC-06 module. So bluetooth is now working. For reasons that are entirely opaque to me, the STM32 could not send any AT serial message other than AT+Name to HC-06. This was true for other HC-06 modules that I had on hand as well.

I'm scratching my head as to why; could it be the serial baud rate (not serial2 baud rate) in the HC06 config.ino file?

instant

[AndrewBCN]

Using a USB/TTL converter, I was able to send AT, AT+VERSION, AT+NAME and AT+BAUD8 to the same HC-06 module. So bluetooth is now working.

Well done!     
As far as I know there are only two GPSDOs in the world that are connected through Bluetooth, and you have one of them. 

For reasons that are entirely opaque to me, the STM32 could not send any AT serial message other than AT+Name to HC-06. This was true for other HC-06 modules that I had on hand as well.
I'm scratching my head as to why; could it be the serial baud rate (not serial2 baud rate) in the HC06 config.ino file?

Honestly I have no idea. But I promise to investigate this when I have some time.

[nealix]

@InstantCrow:

Regarding your STM32 could not send many AT commands, and not sure why;
Have you guys considered that if the BlackPill module had a bad/cheap/china crystal,
and the clock frequency was off, then your baud rate is not the baud rate you think it is....

It might be worth checking two things here;

a.   measure the frequency of the STM32 clock on board and see that it is correct.

b.   verify that the 3.3volt signal levels on the STM32 rx/tx lines are matched to the logic levels on the HC-06 Bluetooth module.
      (Does one require 3.3v logic and the other 5v logic? )

Just checking.

Neal

[nealix]

Ah, indeed, be careful.  Some websites say to run the HC-06 on 5 volts to the VCC pin.  Other web sites say 3.3 volts to VCC.
Another website cautions:  The HC-06 operating voltage is between 3.3V to 5V. However, the tolerance level of RXD pin is 3.3V and not 5V.  Hence, a Logic Level Converter is recommended to convert the 5v input to 3.3V.
You CAN run the HC-06 VCC pin to 3.3 volts and then it should match logic levels to the STM32.   But try it and see if that works, since the schematic for the HC-06 is vague about the RX TX logic levels, and I find differing wiring diagrams online for the same HC-06 modules.   One, for example, is https://www.olimex.com/Products/Components/RF/BLUETOOTH-SERIAL-HC-06/resources/hc06.pdf
Hard to get a straight answer specification for this classic module :-)   It will take some experimenting and measuring.

Neal

[thinkfat]

The data sheet you linked says 3.3V.

It also says it should work between 3.1V and 4.2V, which would be convenient because then you can just hook it up to a LiPo battery without the need for an extra buck converter or voltage regulator (such as the BQ25015 I'm currently playing with). Just a charger circuit would be enough.

But under no circumstance I would dare connecting 5V to a pin labeled 3.3V.

[nealix]

@ThinkFat:

I completely agree.   And my point was that you have to figure out WHICH hc-06 module design you are holding.
Here is a schematic where VCC is 5 v input and then a 5v to 3v regulator, and then 5v pull-up on TX-TTL output.
https://www.olimex.com/Products/Components/RF/BLUETOOTH-SERIAL-HC-06/resources/hc06.pdf

So again, apparently we need to figure out WHICH hc-06 design we have, and keep within it's specs.

Neal

[AndrewBCN]

Hi,
I have tested this single transistor buffer design (see attached files) for the 10MHz sinewave output from the square-to-sine converter filter and it seems to work well enough. I am using the ubiquitous TO-92 2N2222A with a measured hFE of 430. I have calculated the approximate resistor values using an online calculator found here: https://www.changpuak.ch/electronics/BJT_Buffer_Amplifier_4.php

Notes

1. There are much more sophisticated distribution amplifier designs available on the web, using high-speed opamps and surface mounted components, which will probably perform a lot better (lower output impedance) than this single-transistor buffer.

2. This buffer can also be used with the 10MHz squarewave output from the OCXO, or the 2KHz test squarewave from the MCU.

3. As usual, this is optional. Don't use it if you don't need it, but if you need it, it's there.   

[S57UUU]

I use similar buffers. Here, you have about 10k of input impedance, is that OK for your filter?
If needed, you can simply add a resistor to ground (+capacitor, if there is DC)

In fact, if you have a suitable DC level at the output of your filter (assuming your square comes from some logic, and the filter is a lowpass with series inductances), you can connect directly to the base, no cap and 15k,33k resistors.

[AndrewBCN]

I use similar buffers. Here, you have about 10k of input impedance, is that OK for your filter?
If needed, you can simply add a resistor to ground (+capacitor, if there is DC)

In fact, if you have a suitable DC level at the output of your filter (assuming your square comes from some logic, and the filter is a lowpass with series inductances), you can connect directly to the base, no cap and 15k,33k resistors.

Hi S57UUU,

I was wondering about that, and for buffering a TTL/CMOS squarewave, I fully agree that the input cap and 15k, 33k resistors are not needed. But in the case of a sinewave, don't we still need the resistors to setup a minimum current to keep the transistor in its linear region ? Btw I am still experimenting with different resistor values, but the 15k, 33k, 220 trio seems to work well for the sinewave coming out of the filter.

[S57UUU]

This is a emitor follower, the output voltage will be one (B-E) diode drop below the input (base). So, if your input sine does not go below 1V or so, you can connect directly, no resistors and caps. 
If it goes below 1V, you need to "lift" the base with those resistors and a cap - or else use a PNP transistor - in that case,  your input must not go above Vcc-1V.

[cdev]

S57UUU,

Looking at your photos of your EME setup, thatlooks like what I'd like to do when I get my ham ticket, I want to set up a 3meter dish. In my suburban backyard   Why not?