I am currently looking at TMP107 sensor. To read temperature, firstly 2 bytes are transmitted and after 1.5 baud, temperature value is received. I can not calculate baud rate. (I have used 115200 baud for UART)
edit: I uploaded read operation of sensor.
Related
Thank you for reading this.
I'm having difficulties with DVB-S2 communication between two USRP B200 SDR boards that are connected with SMA cable.
For hardware set-up, I'm using Raspberry Pi 4 (4 GB) to execute GNU Radio Companion, and using USB 3.0 port and cable to connect RPi and USRP B200. And I connected a DC block at the Tx port, as described in USRP homepage manual for DVB-S2. (So, the sequence is RPi 4-USB 3.0-USRP (Tx)-DC block-SMA cable (1 m)-USRP (Rx)-USB 3.0-RPi 4)
I have attached my hardware set-up pictures below.
I am trying to send some sample video through DVB-S2 communication. And I got DVB-S2 GRC flowcharts from links below. I've attached the screenshots, too.
https://github.com/drmpeg/gr-dvbs2
https://github.com/drmpeg/gr-dvbs2rx
At last trial, it was successful with RF options setting like below:
-Constellation: QPSK
-Code rate: 2/5
-Center Freq.: 1 GHz
-1 Mbps (sample rate) * 2 sps (sample per symbol) = 2 Mbps (bandwidth)
-Tx relative gain: 40 dB
(Regarding the code rate and bandwidth, I could see the video was received with 0.8 Mbps data rate)
But the problem is:
-this connection is very unstable as it does often fail even when the RF setting is the same.
-I need to raise the data rate as high as possible, but it's too low for me now. As I know, USRP B200 support ~61.44 Msps, but when I require about above 4 Mbps bandwidth, the log shows Us (underflow) at Tx and Os (overflow) at Rx. I confirmed that the clock rate setting is fine with 56 MHz.
-So I tried using other constellations, code rate, sample rate combinations but they failed.And for 8PSK option, I put 3 into sps variable at the Rx side as 8PSK is 3 bits per sample, but Rx flowchart rejected and saying 'sps needs to be even integer >= 2'. And it was not allowed to use 16APSK or beyond constellations in this USRP or in this flowgraph.
I guess I am missing something.
Is there any way that I can make stable connection and raise up the data rate?
I would really appreciate if you could help me.
I have an USRP N320 SDR and I have an issue with 3 MHz-450 MHz band center frequency value. When I have a signal between 450 MHz and 6 GHz, I can see the actual frequency value of the signal even if I slide the center frequency but below 450 MHz, the signal is shifted negatively when I slide the center frequency. Is there any reason and solution for this issue? Any help?
As you can see in Figure 1, the FM radio signals are correctly seen when I set the Rx Tune Frequency to 100 MHz.
1
But when I slide the Rx Tune Frequency to 110, 120,130 and 140 MHz, the FM radio signals' frequency values are also shifted. As you can see in Figure 2, 3 ,4 and 5.
2
3
4
5
Addition:
The main picture of the blocks and parameters of USRP source are below figures.
Blocks
USRP Source 1
USRP Source 2
USRP Source 3
Also I figured out that when I applied below 450 MHz, for example 100 MHz signal and shifted center frequency with an amount, it shifts the signal double time inverse. I might not explain well but below figures does.
100MHz Signal at 100 MHZ center frequency
100MHz Signal at 95 MHz Center frequency but appeared at 90 MHz
100MHz Signal at 110 MHz Center frequency but appeared at 120MHz
But When I applied a signal above 450 MHz, for example 2 GHz, it does work properly. As you can see in figure below.
2 GHz given signal can correctly seen in any other center frequency
So I have been trying to wrap my head around mpeg-ts timing, and the PCR (program clock reference). I understand that this is used for video/audio synchronisation at the decoder.
My basic understanding so far is that everything is driven by a 27 Mhz clock (oscillator). This clock loops at a rate of 27 Mhz, counting from 0 - 299 and keeps repeating itself. Each time this "rollover" from 299 back to 0 occurs, then a 33-bit PCR counter is incremented by 1. In effect, the 33-bit PCR counter is therefore itself running at a rate of 90 kHz. So another way of saying this is that the 27 Mhz clock is divided by 300, giving us a 90 kHz clock.
This 90 kHz clock is then used for the 33-bit PCR counter.
I understand that historically 90 kHz was chosen because mpeg-1 used a 90kHz timebase. [see source here]
Anyway... I have read that the PCR 33-bit count values range from 0x000000000 all the way through to 0x1FFFFFFFF. And according to this, it shows what these values mean in terms of time as we humans understand it (Hours, Mins, Secs, etc):
00:00:00.000 (0x000000000)
to
26:30:43.717 (0x1FFFFFFFF)
So ultimately, my question is relating to how do these hex codes get translated into those time stamps. What would the equations be if someone gave me a hex code, and now I need to reproduce the time stamp?
I would appreciate any help :)
==========
I am closer to an answer myself. Looking at the range from 0x000000000 to 0x1FFFFFFFF, this is basically 0 to 8589934591 in decimal. Since the PCR clock is 90Khz, to get the number of seconds it takes to go from 0 to 8589934591 we can do 8589934591/90000 which gives us 95443.71768 seconds.
Unless you are creating a strict bitrate encoder for broadcast over satellite or terrestrial radio, the PCR doesn't matter that much.
Scenario:
You are broadcasting to a wireless receiver with no return channel, The receiver has a clock running at what it thinks is 90000 ticks per second. Your encoder is also running at 90000 tickets per second. How can you be sure the receiver and the broadcaster have the EXACT same definition of a second? Maybe one side is running a little fast or slow. To keep the clocks in sync, the encoder sends the current time occasionally, This value is the PCR. For example, if you are broadcasting at 15,040,000 bits per second, the receiver receives a 188 byte packet every 0.0000125 seconds. Every now and then (100 ms) the encoder will insert its current time. The receiver can compare this time to its internal clock and determine if is running faster or slower than the broadcast encoder. To keep the strict 235,000 packets per second (15,040,000/(188*8) = 235,000) the encoder will insert null packets. On the internet, the null packets take bandwidth, and have no value, so they are eliminated. Hence the PCR has almost no value anymore because its time is no longer relative the the reception rate.
To answer your question. Set the 27hz value to zero, use a recent DTS minus a small static amount (like 100ms), for the 90khz value.
I am working on UART with pic32mx5xx. All I need is to send a message from pic to terminal (Putty), but it is not working as I would get invalid characters appearing. The baud rate is set to 19200, how do I calculate the clock frequency?
Is it true that the clock frequency of the UART is 16 times the baud rate. If I do the math the clock frequency should be 307200, but this is doesn't seem right.
Can someone help me understand how baud rate and clock frequency relate to each other ? Also how to calculate both?
Thanks!
The baud rate generator has a free-running 16-bit timer. To get the desired baud rate, you must configure its period register UxBRG and prescaler BRGH.
When BRGH is set to 0 (default), the timer is incremented every 16th cycle of peripheral bus clock.
When BRGH is 1, the timer increments every 4th cycle.
It is usually better to set BRGH to 1 to get a smaller baud rate error, as long as the UxBRG value doesn't grow too large to fit into the 16-bit register (on slower baud rates).
The value in the period register UxBRG determines the duration of one pulse on the data line in baud rate generator's timer increments.
See the formulas in section 21.3 - UART Baud Rate Generator in the reference manual to learn how to calculate a proper value for UxBRG.
To compute the period of the 16-bit baud rate generator timer to achieve the desired baud rate:
When BRGH = 0:
UxBRG = FPB / (16 * BAUDRATE) - 1
When BRGH = 1:
UxBRG = FPB / (4 * BAUDRATE) - 1
Where FPB is the peripheral bus clock frequency.
For example, if FPB = 20 MHz and BRGH = 1 and the desired baud rate 19200, you would calculate:
UxBRG = 20000000 / (4 * 19200) - 1
= 259
If you are using some of the latest development libraries and code examples from Microchip you may find that there are already UART methods in the libraries that will set up the PIC for your needs. If you dig deep into the new compiler directory structures you will find help files in the microsoft format (no fear, if you are on a Unix type computer there are Unix utilities that read these types of files.). There you can drill down into the help to find the documentation of various ready made methods you can call from your program to configure the PIC's hardware. Buyer Beware, the code is not that mature. For instance I was working on a PIC project that needed to sample two analog signals. The PIC hardware A/D converter was very complex. But it was clear the ready made code only covered about 10% of that PIC's abilities.
-good luck
I'm trying to transmit serial over the pic18f45k22 eusart peripheral. The messages get sent exactly as expected when the clock is running at 16Mhz, but if I set the PLL to on (so that the the oscillator runs at 64Mhz), I get a framing error.
I have changed the SPBRG registers to account for the new clock frequencey, and tried changing the baudrate generator to both 16 and 8 bit modes, but with no joy.
Current code:
OSCCONbits.IRCF = 0b111; //change Fosc to 16Mhz
OSCTUNEbits.PLLEN = 1; //enable PLL to multiply Fosc by 4
/*Set baud rates and related registers*/
/*For BRG16 = 1 and BRGH = 1, Baud rate = Fosc/(4([SPBRG:SPBRGH]+1)) */
SPBRGH1 = 0; //Set Baud rate control regs to 34 to give baudrate of 115.2k
SPBRG1 = 138;
BAUDCON1bits.BRG16 = 1; //16 bit mode (baudrate generator)
TXSTAbits.BRGH = 1; //Set high speed baud rate
Thanks in advance,
Huggzorx
I'm not familiar with that specific chip but in general, this is what I look at when my UART isn't behaving.
1) Can your clock be divided down to the baud rate with little enough error. Assuming that your baud rate formula in the comments is correct, I think you're okay there:
Baud rate = 16 MHz / (4*(34 + 1)) = 114286 (0.8% error)
Baud rate = 64 MHz / (4*(138 + 1)) = 115107 (0.08% error)
2) Make sure your chip is producing the baud rate you think it should be producing. Some PLLs are really picky about how you turn them on. It's also easy to mis-configure a peripheral. I find that an oscilloscope is your best bet to diagnose this type of problem. If you have access to one, scope the PIC's transmit pin and check that your bit width is 8.68us (1/115200).
If it's 4 times that size (34.72us), then your PLL didn't lock. If it's just a bit off, then the formula might be wrong.
It's not much but hopefully it gets you going in the right direction.