Hi!
due to work overloead I've asked Martin to take over doing the various
design changes of osmo-clock-gen towards v2. As the work progresses, we
have some questions about your preference.
The major changes performed so far in the design:
1) switch from SAMD11 to SAMD21 processor (more flash/ram)
https://osmocom.org/issues/3856
We also used the opportunity of having more UARTs available to use a
different UART on the UEXT than on the 2.5mm console port.
There are no questions here.
2) allow different output voltages for two of the four banks of the Silabs chip
https://osmocom.org/issues/3905
* have jumpers in-line of two of the four output banks of the PLL chipc
* jumper closed: reference is drawn from one (shared) "other voltage" LDO onboard
* jumper open: reference voltage can be provided/injected by user from external reference
What's still open to discuss is whether or not the LDO will be fixed
(you have to change resistors to change the voltage) or adjustable. In
the latter case, we'd apply the DAC output of the SAMD21 as an input to
the tracking input of the LDO. However, this would mean that we'd no
longer have the DAC output for driving a VCTCXO.
Which brings us to
3) should we keep the VCTCXO?
I really only placed it in v1 as PCB space was available. Note that
while v1 can drive the VCTCXO Control voltrage from the microcontroller,
there is no circuitry on board to acually measure/compare/count the
output frequency and hence it's not possible to really have a control
*loop* as the feedback is missing. That makes it rather useless.
So for the v2, we can either
a) remove the VCTCXO altogether and use the DAC output for
software-modifiable output voltage levels of [some of] the clocks, or
b) try to come up with a way to actually count the clock cycles and
compare it against some reference. I'm not sure the SAMD21 could do
a very good job of that, as I'm assuming that all inputs are sampled
to some internal clock and hence experience jitter.
I personally would go for 'a', as to me this board/module was always only
about the PLL, and not about providing a stable reference itself. I'd
much rather have a separate board/module with a GPS-DO, which then
provides a 10MHz reference into any number of osmo-clk-gen boards to
derive any number of other clocks. Sort of like the good old unix
philosophy of doing only one thing in one program and chaining them
together.
Any thoughts?
There's also still to be done:
4) Use SAMD XOSC / PLL / GCLK to allow lower reference frequencies
https://osmocom.org/issues/3857
Where we'd actually use one of the SAMD GCLK outputs as one of the
intputs to the Si5351C, and expose a GCLK input of the SAMD on an
external header. This way, much lower frequencies can be used to
driver the Si5351C. Or one could even go for deriving them from the
SAMD RTC XTAL.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
While this is truly unexpected behaviour, please understand that the device
was designed for a termination load of 75+j0 ohms (that's what all
video/VGA analog signals require to be present at the load side) so any
other load impedance value is untested at factory.
I have independently tested that shorting the output to the ground causes
an instant halt to the output of the plain VGA dongle, so there might be
some protection circuit. Also, the VGA circuit has 150 ohms termination
loads.
Hello.
Managed to compile gr-osmosdr from git with gnuradio
3.8tech-preview-365-gd66bc948 (Python 3.7.3)
Having some issue converting osmosdr-source and sink block files from xml
verion to yml.
Anyone done such they'd be willing to share?
Thank you.
--
If something is requisite, how can it possibly be, prerequisite?
vanitas vanitatum omnia vanitas
later, steve
http://umn.edu/~barbo
Hi. When running the command line
fl2k_fm -c 5000 /dev/zero
to generate a continuous wave, the output voltage of the fl2k dongle
regularly switches between two different amplitude levels (peak to
peak voltage) every 2 or 3 seconds, by about %30 to %70 depending on
the load. There's no visible gradual transition, it just switches
instantly. The output peak-to-peak voltage is about 350 milivolts with
no load. I've calculated the output impedance to be about 750 ohm at
that frequency for the larger output level.
I'm using the HDMI version of the dongle with the wire soldered after
a capacitor (or resistor maybe) which was already there, to the red
VGA pixel output of the chip.
Could the issue be because some signal conditioning circuitry is
missing that is present in the actual VGA version of the dongle, or
that the pin is actually pulled to ground in this dongle as it is
unused, and the chip doesn't like it and for some reason it then
decides to regularly switch voltages? Any other ideas?
If I write software that uses the rtlsdr library that is already installed
on the computer, does my software also have to be opensource?
Thanks,
Richard
Hi all
I am trying to use osmocom fl2k in my macbook pro. I have compiled the software but when I plugged the new falcon 2000 base usb3 to vga adapter I am not getting that in USB list. Please guide me , should i need any specific driver? And the next steps
Thank you
Hello,
I am trying to develop a simple application using rtlsdr's library functions as simple as rtlsdr_get_device_count().
But, at the moment of compilation GCC is unable to find the reference to the function and exit the errors :
« Undefinded reference to the function rtlsdr_get_device_count() ; »
« ld returned 1 exit status »
My code is below :
#include <stdio.h>
#include <stdlib.h>
#include «/usr/include/rtl-sdr.h »
int main(int argc, char *argv[])
{
int device_count ;
device_count = rtlsdr_get_device_count() ;
printf(« Device ID : %d », device_count) ;
return 0 ;
}
That sounds normal because source code and headers files are dispatched in different files and not compiled.
A solution would be to copy each headers, each sources together and compile them. But it should take a lot of times...
It should exists another solution but I don't find it.
For example, in the acarsdec software, how the developer was able to compile his software ?
I hope I well explained my issue,
Thank you in advance for your help
Best regards,
____________________________________________________________________
Justin Guérinot
Intern | Capgemini Digital Engineering & Manufacturing Services
Capgemini France | Toulouse
Mob.: + 33 6 33 77 14 32
www.capgemini.com<http://www.capgemini.com/>
[https://visualidentity.capgemini.com/capgemini.png]
____________________________________________________________________
Connect with Capgemini:
[cid:image002.png@01D41855.E5D1B680]<https://www.capgemini.com/insights-and-resources/blogs>[cid:image003.png@01D41855.E5D1B680]<https://www.twitter.com/capgemini> [cid:image004.png@01D41855.E5D1B680] <https://www.facebook.com/capgemini> [cid:image005.png@01D41855.E5D1B680] <https://www.linkedin.com/company/capgemini> [cid:image006.png@01D41855.E5D1B680] <https://www.youtube.com/capgeminimedia> [cid:image007.png@01D41855.E5D1B680] <https://www.slideshare.net/capgemini> [cid:image009.png@01D41855.E5D1B680] <https://plus.google.com/+CapgeminiGlobal>
Please consider the environment and do not print this email unless absolutely necessary.
Capgemini encourages environmental awareness.
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
This is my first post and I have been experimenting with an rtl-sdr for
only a few weeks. So I am sure I am not doing a lot of things
correctly. But:
I have created a GRC flow graph that does what I want. It has a
rtl-sdr>FIR filter> I/Q samples> file.
I need to create a stand alone program that when run, implements the
same functions but rather then sending the samples to a file, passes
them to my program for further processing.
I intend to run it on a Raspberry Pi so the less overhead the better.
Thanks In Advance.
Pete
Hi
I'm experiencing a "bus error" everytime rtl-sdr tries to interact with my
SDR. Here's a sample:
rtl_fm -f 1000000
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001
Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Tuner gain set to automatic.
[R82XX] PLL not locked!
Tuned to 1252000 Hz.
Oversampling input by: 42x.
Oversampling output by: 1x.
Buffer size: 8.13ms
Exact sample rate is: 1008000.009613 Hz
Allocating 15 zero-copy buffers
Bus error
I'm running Kali on a Raspberry Pi, and I've used the repository version,
and compiled from source — no change. The only thing that makes this error
go away in `rtl_test` is to pass it the -S flag (forcing synchronous) flow.
Does anyone have any idea how to fix this?
If you'd like the Karma and would like to help solve this problem publicly
for future users, Stack Overflow question continuously being updated is
here:
https://stackoverflow.com/questions/54657089/rtl-sdr-crashes-with-bus-error…
―Amin Shah Gilani <https://amin.gilani.me/>
I have managed to replace both buck DC-DC converters with AMS1117 3.3 &
lm317 linear regulators and I successfully got rid of the mentioned 1 MHz
buck converter clock to obtain as pure a signal as possible. Do not expect
miracles as the DAC's are 8-bit and have a best case SNR of -48dB, but
getting the sideband modulation out of the signal surely improves the
resulting spectrum a lot.
I have performed the mod on 4 fl2k adapters.
Two of them came with a 1.2V AMS1117 for the 1.2V and a buck psu for the
3.3V. Another two came with 2 buck psu's
Using 2 LM317 is a bit complex but can be done, as my proof of concept
testbed has demostrated. One could actually fit them inside the plastic
box. Mind you, linear regulators can get quite hot. Still not hot enough to
inflict any damage after a 8-hour operation of the device.
Another notable effect was the total elimination of "cb status 1" message
on the testbed. The testbed suffered a lot of USB connection drops due to
poor power delivery to the chip, which is also the plague of those devices
that is causing bad reviews along with the poor assembly of the cable from
those that use the device in regular vga output mode. The workaround is
extremely simple; we use the onboard capacitors for filtering the output of
the linear regulators, I install them inverted and add metal pins from 1/4W
resistors to patch the power from the pin of the buck chip to the input of
the linear regulator. Same with ground.
Of course we are using USB3 interface that can provide more than 2.5W
(500mA) of output power. I haven't thorougly tested device operation and
stability under USB2.0 which has the aforementioned power limiting. The
device looks stable though.
There are implementations utilizing a pair of AMS1117 from factory.
[image: 20190125_194224_001.jpg]
