Re: [Discuss-gnuradio] A BERT Block with Offset Compensation

2014-10-12 Thread k1gto 
Can you perform the alignment prior to the but comparison stage? This would simplify the comparison so that it can focus on BER alone and no alignment tasks. It would also address the following:Another issue that may arise if the bits streams are not aligned during comparison is that as you slide the window of bits back and forth in search of an alignment match, what's to say the bits won't sometimes match while errors are present. In other words your BER calculation would be skewed as your bit alignment falsely aligns with errors present and then realigns again when errors are not present. I guess it depends on a few things like window size - it should be great enough to minimize the chance of aligning to errors.I would break it out into discrete task/stages. Phase align, bit comparison, etc.Just a few thoughts. [Brad Hein]-Original Message-From: dan.caja...@gmail.comTo: discuss-gnuradio@gnu.orgCc: Sent: 2014-10-12 03:49:58 GMTSubject: [Discuss-gnuradio] A BERT Block with Offset CompensationI am working on a GR block that will test two incoming bit streams (one a reference and one a received result) for equality and return the estimated BER.  Blocks already exist that do this, but they assume the streams are aligned.  My block will allow and correct for offsets in the bit streams.  The goal is to use this with existing physical comm systems - i.e. Generate and transmit a PRBS with GR and USRP to a legacy comm system, capture the RX's data and clock, bring them back into the flowgraph and compare the reference data to the received data to get estimated BER.My block does work for streams that are aligned, but I am having difficulty dealing with misalignment.  Somehow, the blocks needs to have more of the reference signal (if not all of it) to compare against the smaller segments of received data every time the work function is called.I see several possible approaches and the purpose of this email is to solicit advice from those with more experience than I.1) Use set_history() and history() to good effect.I've tried this, but haven't gotten the desired results.  This may be misunderstanding of the feature on my part, but I think the fundamental problem is comparing two streams of equal length when one is offset from the other.2) Accumulate a specified window of reference signal before comparing to received signal.This approach would accumulate the reference signal in a buffer that would be used for comparison.  Until the work function calls accumulated some threshold of reference data in the buffer, the received signal would be passed without comparison or BER calculation.  Once the threshold is met, the small chunks of received data would be compared against the much larger (and growing, but limited to repeat length) reference buffer.I have not implemented this approach yet, but I suspect it will work as long as the window is picked reasonably - the safest bet being the length of the PRBS used in the test.The disadvantage of this method is that the PRBS may be very long, but the sample rate may be slow and therefore there would be a long waiting period as the reference buffer fills before the test even truly begins.3) Variation on previous approach.To alleviate the setup time of filling the reference buffer, perhaps we could generate the whole PRBS in the block constructor.  The block would then have a "menu" of standard PRBS's commonly used int BER testing.  We'd probably want to make a companion PRBS source block with the same menu for the transmitting segment.If anyone has any thoughts on this, I'd appreciate the input.  This is one of those problems that's pretty simple in a standalone python program, but gets a little more complicated when implemented in GR.  But there's a lot of benefit in the implementation too.To anticipate a few questions: For my testing, I have been using no hardware, just a GLFSR source with skiphead to implement offset (delay block adds zeros, which get interpreted as bit errors).  I use a separate sequence to modify the stream with a known number of errors for testing.  As I said, the block works perfectly with no offset.Alignment is implemented by shifting the reference sequence relative to the received sequence, calculating the residual between the two at each step and using the minimum value of that residual as the current error count.  This should be the point where the sequences are most ideally aligned, which works as long as the error rate is relatively low.  The reason alignment doesn't work in my current implementation is because the reference and received sequences are the same length, so if there is any offset, even when aligned, it looks like there are n errors where n is the offset between the sequences.  So, the reference sequence needs to be longer than the reference sequence, and ideally approaching the length of the PRBS itself to correct for any offset.Thanks for suffering through to the end.Very Respectfully,Dan CaJacob

__

Re: [Discuss-gnuradio] Why is fft output complex?

2014-10-11 Thread k1gto 
Thank you this helps a lot. I'll place my complex to mag block directly at the fft output. Then I can send that to a vector sink and review my bin data. [Brad Hein]-Original Message-From: wa1...@wa1hco.netTo: discuss-gnuradio@gnu.orgCc: Sent: 2014-10-11 17:59:24 GMTSubject: Re: [Discuss-gnuradio] Why is fft output complex?
  
  
On 10/11/2014 05:38 PM,
  k1...@comcast.net wrote:

I can't wrap my head around why fft transform of
  complex signal produces a complex output. After all the output
  reflects the amount of energy per frequency bin and frequency bins
  and energy are both real numbers, no?
  
  I'm trying to write a python script to analyze the energy across
  frequency bins but I don't know where to insert a complex to mag
  block. I think if I can understand the fft I will know to put the
  complex to mag. 


The output of an FFT is complex because it contains magnitude _and_
phase.  If the output is I,Q (cartesian coordinates) then the
magnitude is the length of the vector from 0,0 to I,Q or sqrt(i^2 +
q^2).  The phase of the signal is atan2(Q,I).

Note that the FFT transforms Voltage samples into Voltages per
frequency bin.  When you say "energy" you may mean power which is
the magnitude squared or (i^2 + q^2).

jeff, wa1hco

  Thanks
  Brad.
  
  
  
  ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



  

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Why is fft output complex?

2014-10-11 Thread k1gto 
I can't wrap my head around why fft transform of complex signal produces a complex output. After all the output reflects the amount of energy per frequency bin and frequency bins and energy are both real numbers, no?I'm trying to write a python script to analyze the energy across frequency bins but I don't know where to insert a complex to mag block. I think if I can understand the fft I will know to put the complex to mag. ThanksBrad.___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Why am I dropping data over the UDP network?

2014-07-17 Thread k1gto 
Make sure on the server you're binding to 0.0.0.0 (use netstat -na to 
confirm).TCP may help over UDP unless the dropped packets were 
caused by congestion, which seems like a likely culprit. [Brad Hein]Make sure on the server you're binding to 0.0.0.0 (use netstat -na to confirm).TCP may help over UDP unless the dropped packets were caused by congestion, which seems like a likely culprit. [Brad Hein]- Original Message -From: marcus.w...@jhuapl.eduTo: alan.r.h...@gmail.com,discuss-gnuradio@gnu.orgSent:Thu Jul 17 03:50:53 UTC 2014Subject: Re: [Discuss-gnuradio] Why am I dropping data over the UDP network?Alan, I also agree with that, which is why I think it’s probably the reason why I might be losing packets. Right now, I’m experimenting with TCP since during my readings I’ve read that it ensures delivery of all packets and also checks for errors. The current problem with TCP is that I’m getting a socket error: (socket.error:[Errno 111] connection refused) no matter how many ports I open or change it to. Marcus From: discuss-gnuradio-bounces+marcus.ward=jhuapl@gnu.org [mailto:discuss-gnuradio-bounces+marcus.ward=jhuapl@gnu.org] On Behalf Of SilverfoxSent: Wednesday, July 16, 2014 3:49 PMTo: 'GNURadio Discussion List'Subject: Re: [Discuss-gnuradio] Why am I dropping data over the UDP network? It is my understanding that the UDP protocol does not quarentee delivery to the destination.  That  is, it has no recovery mechanism for undelivered packets.Alan  From: discuss-gnuradio-bounces+alan.r.hill=gmail@gnu.org [mailto:discuss-gnuradio-bounces+alan.r.hill=gmail@gnu.org] On Behalf Of Marcus LeechSent: Wednesday, July 16, 2014 11:09 AMTo: rfe...@everestkc.netCc: Discuss-gnuradio@gnu.orgSubject: Re: [Discuss-gnuradio] Why am I dropping data over the UDP network? I'm talking about the UDP traffic between the host and the N2xx device.   on Jul 16, 2014, madengr  wrote:Marcus,What OS are you using? I had the same issue (UDP not getting through onreceive side) with Fedora 20, even with Firewall "supposedly" turned off(i.e. Trusted Zone selected). Manually adding the port exemption (I believeI used port 65000) let the UDP through and it worked.LouKD4HSOWard, Marcus D. wrote> I don't think it's a firewall rule problem, but do you think opening up> ports would solve my problem? I know the port I'm currently using on the> TCP connection is port#: 1234 which deals with Mercurial and git default> ports for serving Hyper Text.> > When I had the UDP connection, I was using the same port (1234) except> that in UDP, that port deals with a VLC media player.--View this message in context: http://gnuradio.4.n7.nabble.com/Why-am-I-dropping-data-over-the-UDP-network-tp49283p49387.htmlSent from the GnuRadio mailing list archive at Nabble.com.___Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Why am I dropping data over the UDP network?

2014-07-16 Thread k1gto 
Take a look at netstat -s and see if that helps isolate if or where 
packet loss is occurring. For example in the udp: section there are statistics 
for total datagrams tx/rx along with dropped, bad checksums, etc. UDP has no retransmission feature built in so bad checksums and bad packets 
get dropped. Any sort of retransmission of dropped packets must be in the 
software. [Brad Hein]Take a look at netstat -s and see if that helps isolate if or where packet loss is occurring. For example in the udp: section there are statistics for total datagrams tx/rx along with dropped, bad checksums, etc. UDP has no retransmission feature built in so bad checksums and bad packets get dropped. Any sort of retransmission of dropped packets must be in the software. [Brad Hein]- Original Message -From: alan.r.h...@gmail.comTo: discuss-gnuradio@gnu.orgSent:Wed Jul 16 07:50:05 UTC 2014Subject: Re: [Discuss-gnuradio] Why am I dropping data over the UDP network?It is my understanding that the UDP protocol does not quarentee delivery to the destination.  That  is, it has no recovery mechanism for undelivered packets.Alan  From: discuss-gnuradio-bounces+alan.r.hill=gmail@gnu.org [mailto:discuss-gnuradio-bounces+alan.r.hill=gmail@gnu.org] On Behalf Of Marcus LeechSent: Wednesday, July 16, 2014 11:09 AMTo: rfe...@everestkc.netCc: Discuss-gnuradio@gnu.orgSubject: Re: [Discuss-gnuradio] Why am I dropping data over the UDP network? I'm talking about the UDP traffic between the host and the N2xx device.   on Jul 16, 2014, madengr  wrote:Marcus,What OS are you using? I had the same issue (UDP not getting through onreceive side) with Fedora 20, even with Firewall "supposedly" turned off(i.e. Trusted Zone selected). Manually adding the port exemption (I believeI used port 65000) let the UDP through and it worked.LouKD4HSOWard, Marcus D. wrote> I don't think it's a firewall rule problem, but do you think opening up> ports would solve my problem? I know the port I'm currently using on the> TCP connection is port#: 1234 which deals with Mercurial and git default> ports for serving Hyper Text.> > When I had the UDP connection, I was using the same port (1234) except> that in UDP, that port deals with a VLC media player.--View this message in context: http://gnuradio.4.n7.nabble.com/Why-am-I-dropping-data-over-the-UDP-network-tp49283p49387.htmlSent from the GnuRadio mailing list archive at Nabble.com.___Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Grc block for measuring sample rate?

2014-07-15 Thread k1gto 
A challenge that I am encountering recently when building flow graphs is with 
upsampling and downsampling and getting the sample rate where I need it. 
Sometimes I have rate mismatches and don't know a good way to take measurements 
with grc so I can troubleshoot. Is there a nifty way to measure the sample rate 
between two blocks in grc?

Thanks!


[Brad Hein]
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio