I want to do real time voice transmission through uart of two raspberry pi 3b.Currently I am able to transmit the real time voice through uart by recording the audio in fifo file and at the same time writing that file to uart(Tx). But at receiving side I am not able to receive data properly.The code i am using is as below.
import os
import serial
import select
ser=serial.Serial('/dev/ttyS0',19200)
os.system('mkfifo audio1.fifo')
with open('audio1.fifo') as fifo:
while True:
select.select([fifo],[],[fifo])
x=ser.readline()
x=fifo.write()
Above code is only creating fifo file but not writing in it.As well ,I also want to do that when it start writing in it it should play audio on 3.5mmm jack. Plz give me some suggestions/corrections.
Related
We are using two USRPs and GNU Radio Companion to build an OFDM radar. The first USRP is the N210 which is used as a transmitter through its Tx/Rx port. The second USRP is N200 which is used as a receiver through its Rx2 port. They are connected together through the so-called MIMO cable to synchronize them. The N210 is connected to the host PC through the gigabit Ethernet cable. The samples that feed the transmitter USRP comes from a block "File Source", and the samples that are collected from the receiver USRP goes to a block "File Sink".
Initially, an external loopback cable is used between the Tx/Rx port of N210 and the the Rx2 port of the N200. Whenever we run the flowgraph, we expect that for every sample that is transferred from the File Source to N210, there should a corresponding sample with somehow same value that comes from N200 to File Sink. However, we have noticed that the N200 produces a stream of random samples before the awaited samples start to appear!!! The length and the values of this stream of random samples varies each time we re-run the flowgraph!!! Of course this issue constitutes an obstacle for our application because in radar the range of the target to be detected is estimated depending on the delay time. The latter is computed from the number of noise samples at the receiver that precedes the reception of the actual transmitted samples.
The question is: How can we guarantee or force the receiving USRP (N200) not to receive any sample before the transmitter USRP (N210) starts to transmit the required samples? Should not this be the task of GnuRadio?!!!! or we have to do something in GnuRadio to force this to happen?
thnx
We are using two USRPs and GNU Radio Companion to build an OFDM radar. The first USRP is the N210 which is used as a transmitter through its Tx/Rx port. The second USRP is N200 which is used as a receiver through its Rx2 port.
This sounds like you're reproducing my 2013 bachelor thesis!
Whenever we run the flowgraph, we expect that for every sample that is transferred from the File Source to N210, there should a corresponding sample with somehow same value that comes from N200 to File Sink.
No, that would only work when you start and stop both USRPs using the same command times and the same number of samples to be acquired.
However, we have noticed that the N200 produces a stream of random samples before the awaited samples start to appear!!!
Well, over-the air delay, and the state in the DSP chain. This is expected. Use timed commands to make the timing deterministic, and you'll know how many samples to ignore.
I want a solution right now...
The LPC1768 which is one of a mbed prototyping boards communicates with processing through Serial whose baud rate is 115200. However, as time passes, the serial communication stops.
As a situation, the LPC1768 sends sensor data with serial.putc() of the default serial library. On the other hand, processing receives the data with serial.read(). The processing code is the following:
if(serial.available()>1) { serial.read(); }
To explore the solution of this problem, I tired these things.
I checked serial.available() is 46 and used serial.clear() in processing, but mbed stopped and didn't send data. Because I thought the cause of this was an overflow of receiving buffer of processing.
I added serial.writable() and check the serial buffers for sending has space. If there are no space, I used the following codes and initialized the serial:
LPC_UART2->FCR |= 0x06;
serial.baud(115200);
, because I thought the cause of this was an overflow of sending buffer of mbed. However, they didn't work.
Please note that these codes work correctly and basically.
However, serial communication stops suddenly. What can I do anything else?
Best regards
I am currently working on a script in docklight v2.0.
My setup is the following:
I have a splitter connected in the USB port of my PC.
That splitter is connected on a wire on which a communication is made between 2 devices.
Docklight is connected on the USB port and receives all the information transmited through that wire.
I have a script on docklight set up to put every byte in a buffer once docklight sniffs them.
My script is coded using the functions in Docklight and VBScript.
The problem I have is the following:
I put all the bytes in the same buffer, that mixes up the messages from both devices and it becomes impossible to analyse them.
What I need to do:
I need to know which byte comes from which device, Docklight is already able to do so, but I need to do that in my script so I can put the bytes in 2 different buffers to treat the data properly.
Using the fonction DL.OnReceive_GetChannel() solved my problem.
I am using a FT232RL chip with FTD2XX_NET.dll I've made a program which writes and reads data to/from AVR atmega32 mcu. First writes data, then reads data as answer.
Now, i want to make an event which indicated me if there's available unreaded data, only when AVR sends data to FTDI buffer and ONLY then. Whithout forcing my program to making loops for checking available data. For my purpose, i want to do the mcu to sends data only when he wants, and the PC must to knows when there's new data in FTDI buffer's chip.
I know that It's impossible for the pc to know when AVR sending data to the FTDI. But this which I mean it's that I need some way for my program to know if FTDI have New unreaded data to it's own buffer.
I don't won't to running read operator over and over in an infinity loop as I do now.
You should create a read thread which does your reading in the background. Then from that thread you can signal an even to notify another part of your application when you have data. I'm not sure what language you are using but you should easily be able to find an example of threading and event notification with a Google search.
I am using EVK1105 development board with AVR Studio 5 as development IDE for my AVR project.
I am using FreeRTOS in it. I have 3 USART ports on this board. One external module is connected to my AVR32 board via USART-RS232 mode. It sends me continuous serial data to my board on USART0 with 19230 baudrate, 7-databits, odd parity, stopbit-1 and normal-channel mode. I created a new task for this purpose. After each 9 data bytes it sends '\n' and '\r'. So in my task I keep on collecting the 9 databytes in a string buffer and then transmit it on USART1. I am using polling method to collect data from USAR0 which is receiving port. But I am facing problem in receiving data. I don't know if its timing issue or something or the scheduler switches the task while collects the data. But I don't get the required data.
Following are things I have already checked as troubleshooting
1. Connected my external module to my PC hyper-terminal which gives me perfect result.
2. Implemented the same thing of using receiving from USART0 and whatever received is transmitted to USART1 as without FreeRTOS. Its works fine.
Please suggest some idea what may be wrong. I am using a queue to communicate between Tx and Rx task to pass the string buffer from USART0 to USART1. Is it problem in handling queue? How can I troubleshoot the queue?
I am using a delay of 50ms in my infinite task loop in Rx Task. Can it create a problem? If I don't use any delay the OS crashes. Please suggest some good practices to create a new task in FreeRTOS so that I will not get any timing issue.
For such a use case, I would not use a polling method with 50ms delay to retrieve data from UART peripheral. You can easily lose received data depending on the system load and UART reception buffer size.
At least use an interrupt on UART data reception that copies every received byte into a local buffer that will be read by your TX thread.
You can have an even better solution using a DMA channel to receive your data frame and be notified when 9 bytes have been received. I don't know if your AVR device has a DMA peripheral or not.
Are you still working on this? The statement of your problem is vague, but there I have several suggestions/leading questions.
1) You may want some documents to see what the registers are
Get the giant datasheet pdfs at
http://www.atmel.com/dyn/products/product_docs.asp?category_id=163&family_id=607&subfamily_id=2138&part_id=4117
2) In this and an earlier post you state that you have, in some cases, been able to RX data. You will need to find the USART HW initialization code from those example projects and get them into the freeRTOS example project. In particular calls to
gpio_enable_module() with {AVR32_USART0_RXD_0_0_PIN, AVR32_USART0_RXD_0_0_FUNCTION}
To connect to USART to CPU
and i believe
InitRs232()
Just doing this requires poking around a lot of code - there's alot of dependencies.
2) What function are you calling to retrieve data from USART0? 19kbaud is approximately 2000bytes/sec or 1 byte/0.5ms, so 50ms polling is not nearly enough. I'd suggest that your RX task poll continuously (never sleep explicitly) but at a lower priority than the TX task.
3) Concentrate on debugging the RX task at the call to retrieve data. Use the debugger to look at the hardware registers for the usart. In particular
USART0 cr register AVR32_USART_CR_RXEN_MASK should be set to enable RX
USART0 csr register AVR32_USART_CSR_RXRDY_MASK will indicate if there is new data there
You can also check the overlow flag to see if you have missed some data.
When the read of USART0 rhr occurs it should be a byte that you sent.
If you are still working on this I can look into this a bit more.