named fifo (byte - byte transfer)
Hi, I did the following: 1) in linux terminal I create a fifo file as : $ mkfifo in 2) in gnuradio I did: file source (file name : in)-> throttle -> file sink (output file: out.txt) [image: image.png] then for running, I did the following: 1) run the flowgraph 2) in terminal, I run $ cat > in then only if I wrote a large number for characters, those characters are transferred. for example if I wrote 10 bytes in fifo in to transmit them, any byte is not written in the file out.txt. while, if 15000 bytes are written in fifo in the some of these 15000 bytes are transferred to out.txt but not all of them. it seems to me that fifo in gnuradio does not transfer each byte alone, is saves a number of bytes as a packet then it send them together. my question is : 1) how to transfer each byte alone in my flowgraph example using unix pipe? 2) if I can not transfer each byte alone, what is the size of packet that are buffered and the transferred together? 3) If the last bytes are less than packet size, then they are not transferred. therefore, how I can I transfer them? if I have to do padding then I have to know the size of the buffer or packet? Is it fixed or not? Thanks for your time and help Best regards
Subject Line Prefix Missing
I've noticed that recent postings to the list are missing the "[Discuss-gnuradio] prefix that was automatically added to the subject line. Was this a deliberate change? I hope not, as I find that feature very useful in picking out the list messages from amid all the spam. @(^.^)@ Ed
Re: named fifo (byte - byte transfer)
Hi, we've covered pretty much exactly your three questions in a mailing list thread earlier this month. Let me link to the archive: https://lists.gnu.org/archive/html/discuss-gnuradio/2019-10/index.html It's the mails with subject "fifo / file source". In essence, "cat" is buffered, and so you need to use a different program that makes sure the fstream it outputs is unbuffered. GNU Radio has no influence on the buffering your writing process does. Best regards, Marcus On Wed, 2019-10-30 at 14:19 +0200, hamzeh elsayed wrote: > Hi, > > I did the following: > 1) in linux terminal I create a fifo file as : > $ mkfifo in > 2) in gnuradio I did: > file source (file name : in)-> throttle -> file sink (output file: out.txt) > > > > then for running, I did the following: > 1) run the flowgraph > 2) in terminal, I run > $ cat > in > > then only if I wrote a large number for characters, those characters are > transferred. > > for example if I wrote 10 bytes in fifo in to transmit them, any byte is not > written in the file out.txt. while, if 15000 bytes are written in fifo in the > some of these 15000 bytes are transferred to out.txt but not all of them. > > it seems to me that fifo in gnuradio does not transfer each byte alone, is > saves a number of bytes as a packet then it send them together. > > my question is : > > 1) how to transfer each byte alone in my flowgraph example using unix pipe? > > 2) if I can not transfer each byte alone, what is the size of packet that are > buffered and the transferred together? > > 3) If the last bytes are less than packet size, then they are not > transferred. therefore, how I can I transfer them? > > if I have to do padding then I have to know the size of the buffer or packet? > Is it fixed or not? > > Thanks for your time and help > > Best regards smime.p7s Description: S/MIME cryptographic signature
Re: Subject Line Prefix Missing
Hi Ed, "deliberate" would be wrong. Surprising, not really, if we'd have read the info mails from the gnu.org mailing list admin more carefully: In the process of respecting DMARC in the ML infrastructure, they disabled rewriting of the subject line for outgoing mail servers that signal strict DMARC compliance. The mailing list seems to think your server does (I don't know why, to be honest, can't seem to find those DNS entries). So, for now, my understanding is that there's nothing *we* can do about it. (We should be able to change the settings of the ML; but in which range, and what we'd break on the way, isn't quite clear to us at this point.) For some reason, my university mail server seems to sort these mails correctly, and so do GMail instances. Probably a list header? Best regards, Marcus On Wed, 2019-10-30 at 09:17 -0400, Ed Criscuolo wrote: > I've noticed that recent postings to the list are missing > the "[Discuss-gnuradio] prefix that was automatically > added to the subject line. > > Was this a deliberate change? I hope not, as I find that > feature very useful in picking out the list messages > from amid all the spam. > > > @(^.^)@ Ed > smime.p7s Description: S/MIME cryptographic signature
Re: Lunar Orbiting Platform Gateway
Hey John, > > Anyone working on… > Definitely not Does that imply they're finished? Best regards, Marcus smime.p7s Description: S/MIME cryptographic signature
Re: Subject Line Prefix Missing
Hi all, I was wondering about that mailing list behavior as well. My solution 1. If "Mail From 'discuss-gnuradio@gnu.org'" 2. If "Mail To 'discuss-gnuradio@gnu.org'" In my case: move to folder. 1. covers original mails 2. covers replies. I had to split this into 2 separate rules but that's due to my email service provider. This solution is more verbose about who receives such an email. e.g. off-list replies should not end up to be caught by these rules. Anyways, I just wanted to share my 2 cents on that. Maybe someone finds this info useful. Cheers Johannes On 30.10.19 15:11, Müller, Marcus (CEL) wrote: > Hi Ed, > > "deliberate" would be wrong. Surprising, not really, if we'd have read > the info mails from the gnu.org mailing list admin more carefully: > > In the process of respecting DMARC in the ML infrastructure, they > disabled rewriting of the subject line for outgoing mail servers that > signal strict DMARC compliance. The mailing list seems to think your > server does (I don't know why, to be honest, can't seem to find those > DNS entries). > > So, for now, my understanding is that there's nothing *we* can do about > it. (We should be able to change the settings of the ML; but in which > range, and what we'd break on the way, isn't quite clear to us at this > point.) > > For some reason, my university mail server seems to sort these mails > correctly, and so do GMail instances. Probably a list header? > > Best regards, > Marcus > > On Wed, 2019-10-30 at 09:17 -0400, Ed Criscuolo wrote: >> I've noticed that recent postings to the list are missing >> the "[Discuss-gnuradio] prefix that was automatically >> added to the subject line. >> >> Was this a deliberate change? I hope not, as I find that >> feature very useful in picking out the list messages >> from amid all the spam. >> >> >> @(^.^)@ Ed >>
Re: Lunar Orbiting Platform Gateway
I was hesitant to ask why, but I'm curious now. I know the Gateway is controversial. I understand there's a lot of doubt it will actually happen. The heavy emphasis on commercial activity is another aspect. However, I've been asked for help on a receiving station for the amateur radio portions that might be included. There's a lot of overlap between what I do and the type of communications proposed. Comment and critique would be very appreciated here. -Michelle W5NYV On Wed, Oct 30, 2019 at 7:14 AM Müller, Marcus (CEL) wrote: > Hey John, > > > > Anyone working on… > > Definitely not > > Does that imply they're finished? > > Best regards, > Marcus >
Re: Subject Line Prefix Missing
Hi, FWIW, I filter mailing lists based on the List-Id field, which still works fine. Just found out that this seems to be a thing :-) https://www.ietf.org/rfc/rfc2919.txt Best, Bastian On 10/30/19 3:21 PM, Johannes Demel wrote: > Hi all, > > I was wondering about that mailing list behavior as well. > > My solution > 1. If "Mail From 'discuss-gnuradio@gnu.org'" > 2. If "Mail To 'discuss-gnuradio@gnu.org'" > In my case: move to folder. > 1. covers original mails > 2. covers replies. > > I had to split this into 2 separate rules but that's due to my email > service provider. > This solution is more verbose about who receives such an email. e.g. > off-list replies should not end up to be caught by these rules. > > Anyways, I just wanted to share my 2 cents on that. Maybe someone finds > this info useful. > > Cheers > Johannes > > > > On 30.10.19 15:11, Müller, Marcus (CEL) wrote: >> Hi Ed, >> >> "deliberate" would be wrong. Surprising, not really, if we'd have read >> the info mails from the gnu.org mailing list admin more carefully: >> >> In the process of respecting DMARC in the ML infrastructure, they >> disabled rewriting of the subject line for outgoing mail servers that >> signal strict DMARC compliance. The mailing list seems to think your >> server does (I don't know why, to be honest, can't seem to find those >> DNS entries). >> >> So, for now, my understanding is that there's nothing *we* can do about >> it. (We should be able to change the settings of the ML; but in which >> range, and what we'd break on the way, isn't quite clear to us at this >> point.) >> >> For some reason, my university mail server seems to sort these mails >> correctly, and so do GMail instances. Probably a list header? >> >> Best regards, >> Marcus >> >> On Wed, 2019-10-30 at 09:17 -0400, Ed Criscuolo wrote: >>> I've noticed that recent postings to the list are missing >>> the "[Discuss-gnuradio] prefix that was automatically >>> added to the subject line. >>> >>> Was this a deliberate change? I hope not, as I find that >>> feature very useful in picking out the list messages >>> from amid all the spam. >>> >>> >>> @(^.^)@ Ed >>> -- Dr. Bastian Bloessl Secure Mobile Networking Lab (SEEMOO) TU Darmstadt, Germany www.bastibl.net GitHub/Twitter: @bastibl
Re: Subject Line Prefix Missing
This is getting OT, but... On Wed, Oct 30, 2019 at 02:21:12PM +, Johannes Demel wrote: > My solution > 1. If "Mail From 'discuss-gnuradio@gnu.org'" > 2. If "Mail To 'discuss-gnuradio@gnu.org'" Mailing list software for decades inserts unique headers for filtering purpose. "List-Id" is AFAICT the most common one, which is also used by GNU mailman. It has been specified in 2001 in RFC2919 http://www.faqs.org/rfcs/rfc2919.html Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
FM and FreeDV cross-mode repeater with qradiolink
Hi, I just wanted to let you know that I have created an AppImage of qradiolink based on Debian Buster libraries. There have been some changes recently, and now the VOIP GUI can do cross-mode repeat from FM to FreeDV and viceversa. Other modes like AM and SSB work a little as well, but despite all my efforts I was unable to write a good enough SSB demodulator. I think I have either a problem understanding the AGC in GNU radio or a problem understanding how SSB should be demodulated. Many thanks to A. Maitland Bottoms who exposed the FreeDV API and maintains the Debian GNU radio package, making it possible for people like me who don't own SSB radios anymore to use FreeDV. Link: https://github.com/qradiolink/qradiolink/releases/download/0.8.2-2/QRadioLink-0.8.2-2-x86_64.AppImage Best regards, Adrian
Re: Subject Line Prefix Missing
To drive this more Off-Topic than it already is... > Mailing list software for decades inserts unique headers for filtering > purpose. "List-Id" is AFAICT the most common one, which is also used > by GNU mailman. It has been specified in 2001 in RFC2919 Even non-Mailinglist software, e.g. GitHub, EBay, Deutsche Bahn, are supplying custom List-Id headers for separate topics. In case of GitHub one can use List-Id headers to automatically separate mails for different repositories without looking at the content or Subject. Cheers Andrej
Re: Lunar Orbiting Platform Gateway
It was a cheap joke on my part (and not at all commentary on the gateway concept). Disregard. I'd be down to collaborate on something open source. Could you point to publicly available documents that summarize the standards/specs? -John On Wed, Oct 30, 2019 at 8:50 AM Michelle Thompson < mountain.miche...@gmail.com> wrote: > I was hesitant to ask why, but I'm curious now. > > I know the Gateway is controversial. I understand there's a lot of doubt > it will actually happen. The heavy emphasis on commercial activity is > another aspect. > > However, I've been asked for help on a receiving station for the amateur > radio portions that might be included. There's a lot of overlap between > what I do and the type of communications proposed. > > Comment and critique would be very appreciated here. > > -Michelle W5NYV > > > > > On Wed, Oct 30, 2019 at 7:14 AM Müller, Marcus (CEL) > wrote: > >> Hey John, >> >> > > Anyone working on… >> > Definitely not >> >> Does that imply they're finished? >> >> Best regards, >> Marcus >> >
Re: Lunar Orbiting Platform Gateway
Hi - I am involved in recommending the radio communications architecture for Gateway which is baselined to utilize CCSDS (see cases.org) protocols. For long-haul RF links (Gateway to Earth) Unified Space Link Protocol (USLP). For short-haul RF (Gateway to lunar surface): Proximity-1 and AOS For proximity wireless networks (around Gateway and on lunar surface) 802.11 n/ac baselined, 802.11ax and LTE are under strong consideration. Please feel free to respond directly if additional information is needed and I’ll strive to assist. Kevin From: Discuss-gnuradio on behalf of John Malsbury Sent: Wednesday, October 30, 2019 12:34 PM To: Michelle Thompson Cc: discuss-gnuradio@gnu.org Subject: Re: Lunar Orbiting Platform Gateway It was a cheap joke on my part (and not at all commentary on the gateway concept). Disregard. I'd be down to collaborate on something open source. Could you point to publicly available documents that summarize the standards/specs? -John On Wed, Oct 30, 2019 at 8:50 AM Michelle Thompson mailto:mountain.miche...@gmail.com>> wrote: I was hesitant to ask why, but I'm curious now. I know the Gateway is controversial. I understand there's a lot of doubt it will actually happen. The heavy emphasis on commercial activity is another aspect. However, I've been asked for help on a receiving station for the amateur radio portions that might be included. There's a lot of overlap between what I do and the type of communications proposed. Comment and critique would be very appreciated here. -Michelle W5NYV On Wed, Oct 30, 2019 at 7:14 AM Müller, Marcus (CEL) mailto:muel...@kit.edu>> wrote: Hey John, > > Anyone working on… > Definitely not Does that imply they're finished? Best regards, Marcus
Re: Lunar Orbiting Platform Gateway
And you mentioned something about amateur radio portions, Michelle? On Wed, Oct 30, 2019 at 11:52 AM Kevin K Gifford wrote: > Hi - > > I am involved in recommending the radio communications architecture for > Gateway which is baselined to utilize CCSDS (see cases.org) protocols. > > For long-haul RF links (Gateway to Earth) Unified Space Link Protocol > (USLP). > > For short-haul RF (Gateway to lunar surface): Proximity-1 and AOS > > For proximity wireless networks (around Gateway and on lunar surface) > 802.11 n/ac baselined, 802.11ax and LTE are under strong consideration. > > Please feel free to respond directly if additional information is needed > and I’ll strive to assist. > > Kevin > -- > *From:* Discuss-gnuradio colorado@gnu.org> on behalf of John Malsbury < > jmalsbury.perso...@gmail.com> > *Sent:* Wednesday, October 30, 2019 12:34 PM > *To:* Michelle Thompson > *Cc:* discuss-gnuradio@gnu.org > *Subject:* Re: Lunar Orbiting Platform Gateway > > It was a cheap joke on my part (and not at all commentary on the gateway > concept). Disregard. > > I'd be down to collaborate on something open source. Could you point to > publicly available documents that summarize the standards/specs? > > -John > > On Wed, Oct 30, 2019 at 8:50 AM Michelle Thompson < > mountain.miche...@gmail.com> wrote: > > I was hesitant to ask why, but I'm curious now. > > I know the Gateway is controversial. I understand there's a lot of doubt > it will actually happen. The heavy emphasis on commercial activity is > another aspect. > > However, I've been asked for help on a receiving station for the amateur > radio portions that might be included. There's a lot of overlap between > what I do and the type of communications proposed. > > Comment and critique would be very appreciated here. > > -Michelle W5NYV > > > > > On Wed, Oct 30, 2019 at 7:14 AM Müller, Marcus (CEL) > wrote: > > Hey John, > > > > Anyone working on… > > Definitely not > > Does that imply they're finished? > > Best regards, > Marcus > >
Re: Lunar Orbiting Platform Gateway
ccsds.org (not cases.org, auto-correct got me)... Kevin From: Discuss-gnuradio on behalf of Kevin K Gifford Sent: Wednesday, October 30, 2019 12:52 PM To: John Malsbury ; Michelle Thompson Cc: discuss-gnuradio@gnu.org Subject: Re: Lunar Orbiting Platform Gateway Hi - I am involved in recommending the radio communications architecture for Gateway which is baselined to utilize CCSDS (see cases.org) protocols. For long-haul RF links (Gateway to Earth) Unified Space Link Protocol (USLP). For short-haul RF (Gateway to lunar surface): Proximity-1 and AOS For proximity wireless networks (around Gateway and on lunar surface) 802.11 n/ac baselined, 802.11ax and LTE are under strong consideration. Please feel free to respond directly if additional information is needed and I’ll strive to assist. Kevin From: Discuss-gnuradio on behalf of John Malsbury Sent: Wednesday, October 30, 2019 12:34 PM To: Michelle Thompson Cc: discuss-gnuradio@gnu.org Subject: Re: Lunar Orbiting Platform Gateway It was a cheap joke on my part (and not at all commentary on the gateway concept). Disregard. I'd be down to collaborate on something open source. Could you point to publicly available documents that summarize the standards/specs? -John On Wed, Oct 30, 2019 at 8:50 AM Michelle Thompson mailto:mountain.miche...@gmail.com>> wrote: I was hesitant to ask why, but I'm curious now. I know the Gateway is controversial. I understand there's a lot of doubt it will actually happen. The heavy emphasis on commercial activity is another aspect. However, I've been asked for help on a receiving station for the amateur radio portions that might be included. There's a lot of overlap between what I do and the type of communications proposed. Comment and critique would be very appreciated here. -Michelle W5NYV On Wed, Oct 30, 2019 at 7:14 AM Müller, Marcus (CEL) mailto:muel...@kit.edu>> wrote: Hey John, > > Anyone working on… > Definitely not Does that imply they're finished? Best regards, Marcus
