[snip] ... but wondered if anyone had worked on the GR porting of the code. I assume, that is not the case.
No that I know of.
What would be the interest exactly ?
I mean GR is great for signal processing but once you got the bits, the rest is IMHO way better handled outside gnuradio itself. All the phy/mac levels are no trivial and will need state processing and such ... not something I really see in GR.
Using fifo on the filesystem you can pipe directly/live the flow of info from GR outpout to the tetra-rx input.
Cheers,
Sylvain
BTW, you forgot to CC the list in your reply. (I assume it was your intent because of the "with everyone here" comment at the end of your mail).
On 01/27/2011 11:08 AM, Sylvain Munaut wrote:
[snip] ... but wondered if anyone had worked on the GR porting of the code. I assume, that is not the case.
No that I know of.
My plan is to create a GNU Radio block that will give us the softbits. I was a bit sad that GNU Radio only has python bindings to script things but not to do any work.
Hi Sylvain, Thanks for posting it to the list, I just hit reply, I thought the list is the main "to" part of the reply, but now I know, I have to put reply-all instead.
What I am using GR is use the AIR interface of the TETRA in a simple way, I would like to create a system similar to OpenBTS to handle TETRA. The main problem I have is I am a pure HW design engineer and my knowledge of Linux, Python and high level SW is not very strong, but I am learning.
Best regards, Farhad
________________________________ From: Sylvain Munaut 246tnt@gmail.com To: Farhad Abdolian f.abdolian@yahoo.com Cc: tetra@lists.osmocom.org Sent: Thu, January 27, 2011 11:08:52 AM Subject: Re: TETRA and GRC?
[snip] ... but wondered if anyone had worked on the GR porting of the code. I assume, that is not the case.
No that I know of.
What would be the interest exactly ?
I mean GR is great for signal processing but once you got the bits, the rest is IMHO way better handled outside gnuradio itself. All the phy/mac levels are no trivial and will need state processing and such ... not something I really see in GR.
Using fifo on the filesystem you can pipe directly/live the flow of info from GR outpout to the tetra-rx input.
Cheers,
Sylvain
BTW, you forgot to CC the list in your reply. (I assume it was your intent because of the "with everyone here" comment at the end of your mail).
On Thu, Jan 27, 2011 at 02:25:31AM -0800, Farhad Abdolian wrote:
Hi Sylvain, Thanks for posting it to the list, I just hit reply, I thought the list is the main "to" part of the reply, but now I know, I have to put reply-all instead.
What I am using GR is use the AIR interface of the TETRA in a simple way, I would like to create a system similar to OpenBTS to handle TETRA. The main problem I have is I am a pure HW design engineer and my knowledge of Linux, Python and high level SW is not very strong, but I am learning.
Please understand that it is quite a big task to do this. A receive-only implementation like what we have now is relatively simple, but in order to run a full TETRA system, you need to implement all the protocols like LLC, LME, MM, CC and their associated logic, which is a huge task.
Getting something like a small transmitter goign that continuously transmits a BSCH/BNCH should be a simple task that you can start with. Basically use the same code that we use in conv_enc_test.c to generate the type-5 bits, feed them into the DQPSK modulator and try to see if TETRA handsets can recognize the signal.
Hi Harald, I am aware of the complexity of the TETRA system, I just want to implement the physical layer (Layer 1) and if I can also the Layer 2 of the protocol and be able to show that it can be done with GR. I want to create both the RX and TX path using GnuRadio.
I am working on implement the blocks similar to those on Figure 4.1 and 4.2 of EN 300 392-2: V3.4.1 (2010-08).
That shouldn't be such a difficult task.
Best regards, Farhad
________________________________ From: Harald Welte laforge@gnumonks.org To: Farhad Abdolian f.abdolian@yahoo.com Cc: Sylvain Munaut 246tnt@gmail.com; tetra@lists.osmocom.org Sent: Thu, January 27, 2011 5:35:20 PM Subject: Re: TETRA and GRC?
On Thu, Jan 27, 2011 at 02:25:31AM -0800, Farhad Abdolian wrote:
Hi Sylvain, Thanks for posting it to the list, I just hit reply, I thought the list is the
main "to" part of the reply, but now I know, I have to put reply-all instead.
What I am using GR is use the AIR interface of the TETRA in a simple way, I would like to create a system similar to OpenBTS to handle TETRA. The main problem I have is I am a pure HW design engineer and my knowledge of Linux, Python and high level SW is not very strong, but I am learning.
Please understand that it is quite a big task to do this. A receive-only implementation like what we have now is relatively simple, but in order to run a full TETRA system, you need to implement all the protocols like LLC, LME, MM, CC and their associated logic, which is a huge task.
Getting something like a small transmitter goign that continuously transmits a BSCH/BNCH should be a simple task that you can start with. Basically use the same code that we use in conv_enc_test.c to generate the type-5 bits, feed them into the DQPSK modulator and try to see if TETRA handsets can recognize the signal.
-
Farhad Abdolian -
Harald Welte -
Holger Hans Peter Freyther -
Sylvain Munaut