Si5351

[w4mmp]

Hi,

I am attempting to port this code to a Raspberry Pi 2. I do not know the USI_TWI routings. The question I have is what is the slave address of the Si5351? Is it: define SI5351_BUS_BASE_ADDR 0xC0?

If so, I thought the address of the Si5351 is 0x60.
Regards,
Ron

[NT7S]

Yes, that is absolutely correct. In the very first shipment of Si5351A that I received, I accidentally got some customer parts with a different address, and my initial library had that address. I must have forgotten to use an up to date file here.

I'll change it in the repo right away. I plan to do a big overhaul of all of the derivative libraries from the Si5351Arduino library once I make some changes to it.

[w4mmp]

Hi Jason,

Just wanted to let you know that I ported your your Si5351 (AVR) library
to the Raspberry Pi 2 today and the RPi 2 is now talking to an Adafruit
Si5351 breakout board. Cool stuff!

I am confused about something. I see you have several different
versions of the library on github. The first one I chose I had
absolutely no luck porting (https://github.com/NT7S/Si5351) and I see
the last update was 2 years ago. I ported the avr-tiny-minimal and I
had it ported in a few hours. So, the question is which version should
I be working with (the Arduino or the AVR) ?

73
Ron / W4MMP

On 2/6/2016 20:46, Jason Milldrum wrote:

Yes, that is absolutely correct. In the very first shipment of Si5351A
that I received, I accidentally got some customer parts with a
different address, and my initial library had that address. I must
have forgotten to use an up to date file here.

I'll change it in the repo right away. I plan to do a big overhaul of
all of the derivative libraries from the Si5351Arduino library once I
make some changes to it.

—
Reply to this email directly or view it on GitHub
#1 (comment).

[NT7S]

Ron, the most well developed version of the library is the Arduino version: https://github.com/etherkit/Si5351Arduino

You may want to try to adapt that code for the RasPi. Theoretically, the only changes that would necessary would be to the I2C driver code, so if you already have that in place for this version of the library it shouldn't be too difficult to port to the Arduino version. This version of the Si5351 library was intended for microcontrollers with very limited flash memory space, something that's not an issue for the RasPi, so I would think your best bet would be to use the full-featured Arduino version for your RasPi port.

Good luck!

[w4mmp]

Hi,

Well at the risk of boring you :-) . The reason for porting to the RPi
2 was have an easier platform to test on. The real target is a Cypress
PSoC 5 microprocessor. I know , convoluted, but it's the way I work.

I will take a look at the Arduino version in a few days, after I have
the AVR version working on the PSoC 5. But to tell the truth, I'm not
really sure I need anything more than the AVR version. But it is early
in the development cycle.

Thanks very much for the Si5351 library. It sure saved me a boat load
of time!

73
Ron / W4MMP

On 2/6/2016 22:13, Jason Milldrum wrote:

Ron, the most well developed version of the library is the Arduino
version: https://github.com/etherkit/Si5351Arduino

You may want to try to adapt that code for the RasPi. Theoretically,
the only changes that would necessary would be to the I2C driver code,
so if you already have that in place for this version of the library
it shouldn't be too difficult to port to the Arduino version. This
version of the Si5351 library was intended for microcontrollers with
very limited flash memory space, something that's not an issue for the
RasPi, so I would think your best bet would be to use the
full-featured Arduino version for your RasPi port.

Good luck!

—
Reply to this email directly or view it on GitHub
#1 (comment).

[w4mmp]

I would like to thank you again for your Si5351 library. The code is now ported and working on a Cypress PSoC 5 development board.
73,
Ron / W4mmp

[NT7S]

Very cool! I love hearing about people extending and porting my code. Thanks much for the report and best of luck in your future endeavors with the Si5351.

[w4mmp]

Hi,

If I may, I have one question. Really only one :-) . Why is the input
frequency size to si5351_set_freq an unsigned 64 bit? That pretty much
covers the entire universe (just kidding).

73
Ron / W4MMP

On 2/9/2016 14:22, Jason Milldrum wrote:

Very cool! I love hearing about people extending and porting my code.
Thanks much for the report and best of luck in your future endeavors
with the Si5351.

—
Reply to this email directly or view it on GitHub
#1 (comment).

[w4mmp]

Hello Jason,
Its me again :)
One of my team members has noticed the Si5351 output becomes unstable when generating an LO of or above 29.3 MHz X 4 (117.2MHz). Do you have any insights into this. Is it a possible issue with this version of the source code or are we looking a hardware issue?
73
Ron / W4MMP

[NT7S]

Ron,

The question about the uint64 is fair game. Obviously, that much space itself is not needed for the output frequency, but in the course of the math I was doing in the original version of the library, everything was converted to 64-bit math in order to get the required precision, so I just stuck with 64-bits for the input variable as well. In this version of the library, I imagine it could be changed to a uint32, but I haven't really studied all of the implications of that yet, so don't quote it as official word quite yet.

Regarding the output above 117.2 MHz, that sounds suspiciously like a bug in my earliest versions of the library, so I'm almost certain it's not a hardware issue. You and your team may want to compare to the latest version of the Arduino library to see if you can find the bug, as I'm going to be out of commission for a few weeks. I'll be happy to merge a pull request if you find the cause.

Thanks,
Jason

[w4mmp]

Hi Jason,

Thanks so much for getting back to me. Thanks for the uint64 info. No
biggie. It was a curiosity more than anything.

ON the 10M+ issue. The issue exists in both the Arduino and Attiny
version. There are currently two transceivers in development that use
your source code. One is by HobbyPCB (Jim Veatch) and the other is by
my rag tag crew (Omnia SDR). HobbyPCB is using the Arduino version and I
am using the Attiny version. They both exhibit the very same issue in
the 10M band. My RF engineer and I are looking at the code now to see
where it might be going sideways. One of the first steps I am taking
is to generate the register header file via Silicon Labs Clock builder
desktop application. Those numbers will then be plugged into code and
see what happens. I will let you know when we find something.

73,
Ron / W4MMP

On 5/20/2016 17:20, Jason Milldrum wrote:

Ron,

The question about the uint64 is fair game. Obviously, that much space
itself is not needed for the output frequency, but in the course of
the math I was doing in the original version of the library,
everything was converted to 64-bit math in order to get the required
precision, so I just stuck with 64-bits for the input variable as
well. In this version of the library, I imagine it could be changed to
a uint32, but I haven't really studied all of the implications of that
yet, so don't quote it as official word quite yet.

Regarding the output above 117.2 MHz, that sounds suspiciously like a
bug in my earliest versions of the library, so I'm almost certain it's
not a hardware issue. You and your team may want to compare to the
latest version of the Arduino library to see if you can find the bug,
as I'm going to be out of commission for a few weeks. I'll be happy to
merge a pull request if you find the cause.

Thanks,
Jason

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#1 (comment)

[NT7S]

Ron,

I wasn't aware of the HobbyPCB transceiver, so thanks for letting me know about that. If it's being seen across both versions, then there's obviously a bigger issue at hand, and I'd like to fix it. I have been able to generate signals in the 2 meter band just fine with the current Arduino library, so I wonder if there's a math problem causing a problem in a certain range of frequencies.

I definitely want to investigate this further, unfortunately right now is a bad time, as I'll be away from my lab for the next 10 days. Let me know what you find in the mean time, and I'll get to work on it when I return. If you haven't found anything by then, I'll gather more specifics from you. Also, I assume you are in touch with Jim Veatch, so if you have any specifics about the failure from him to pass along as well, that would be great.

Thanks much for your bug report!

[w4mmp]

Hi Jason,

Thanks for opening the ticket. I am working on the issue as I type
this. I have modified the test code I use on a Raspberry Pi 2 to
display the values being sent to the Si5351. I have also performed a
run of Clock Builder Desktop. The idea is to compare the two outputs
for a given input frequency and determine the difference if any. The
first step however is to send the values created by Clock Builder and
determine if we obtain a stable output.

I will update the ticket as I progress thru the trouble shooting.

Thanks again for taking interest in our problem(s)!

73,
Ron / W4MMP

On 5/21/2016 12:31, Jason Milldrum wrote:

Ron,

I wasn't aware of the HobbyPCB transceiver, so thanks for letting me
know about that. If it's being seen across both versions, then there's
obviously a bigger issue at hand, and I'd like to fix it. I have been
able to generate signals in the 2 meter band just fine with the
current Arduino library, so I wonder if there's a math problem causing
a problem in a certain range of frequencies.

I definitely want to investigate this further, unfortunately right now
is a bad time, as I'll be away from my lab for the next 10 days. Let
me know what you find in the mean time, and I'll get to work on it
when I return. If you haven't found anything by then, I'll gather more
specifics from you. Also, I assume you are in touch with Jim Veatch,
so if you have any specifics about the failure from him to pass along
as well, that would be great.

Thanks much for your bug report!

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#1 (comment)

[w4mmp]

Hello Jason,
Here is what I have found so far. First it is not as you have mentioned, a hardware issue. I have successfully programmed the Si5351 with a data file created by Clock Builder Desktop. At 29.7MHz x 4 (118.8MHz) the wave form is clean and stable.
Please find attached two output files.

1. The data that is sent to the Si5351 by the source routine: si5351_set_freq. (failure.txt)
2. The data that is sent to the Si5351 based on the Clock Builder Desktop. (success.txt)

I have not preformed an comparison analysis yet. I need to come up to speed on what the various registers do.
Regards,
Ron W4MMP
results.zip

[w4mmp]

Hi Jason,
Do you have any further information regarding the 10M frequency stability issue?
Regards,
Ron / W4MMP

[NT7S]

I'm in the middle of doing quite a rewrite of the Arduino library frequency setting methods, and I intend to see if I can adapt the new scheme in that library to this one. Sorry it's taking a while, I've got lots of personal matters I've been attending to, with almost no time for anything else. Those are starting to come to an end, so I'll be able to work more on coding and radio again soon.

[w4mmp]

Hello Jason,

Thank you very much. Yes, life has a way of interfering with our
hobbies ;-)

73,
Ron / W4MMP

On 10/5/2016 13:34, Jason Milldrum wrote:

I'm in the middle of doing quite a rewrite of the Arduino library
frequency setting methods, and I intend to see if I can adapt the new
scheme in that library to this one. Sorry it's taking a while, I've
got lots of personal matters I've been attending to, with almost no
time for anything else. Those are starting to come to an end, so I'll
be able to work more on coding and radio again soon.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#1 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AInsTtTSWtZ25s4-DN5UGRu5iWyL6N7bks5qw9-hgaJpZM4HU3Xw.