I'm working on an SDR project where I need to transmit a narrow
baseband signal on multiple different carriers simultaneously, over a
relatively wide bandwidth (1Mhz). … an external audio
source is then AM modulated and transmitted on several channels …
In my case the output channels are arbitrary, …
And you mentioned something about amateur radio portions, Michelle?On Wed, Oct 30, 2019 at 11:52 AM Kevin K Gifford <kevin.gifford@colorado.edu> 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 <discuss-gnuradio-bounces+kevin.gifford=colorado.edu@gnu.org> on behalf of John Malsbury <jmalsbury.personal@gmail.com>
Sent: Wednesday, October 30, 2019 12:34 PM
To: Michelle Thompson <mountain.michelle@gmail.com>
Cc: discuss-gnuradio@gnu.org <discuss-gnuradio@gnu.org>
Subject: Re: Lunar Orbiting Platform GatewayIt 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.michelle@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) <mueller@kit.edu> wrote:
Hey John,
> > Anyone working on…
> Definitely not
Does that imply they're finished?
Best regards,
Marcus
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) <mueller@kit.edu> wrote:
Hey John,
> > Anyone working on…
> Definitely not
Does that imply they're finished?
Best regards,
Marcus
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 <discuss-gnuradio-bounces+kevin.gifford=colorado.edu@gnu.org> on behalf of John Malsbury <jmalsbury.personal@gmail.com>
Sent: Wednesday, October 30, 2019 12:34 PM
To: Michelle Thompson <mountain.michelle@gmail.com>
Cc: discuss-gnuradio@gnu.org <discuss-gnuradio@gnu.org>
Subject: Re: Lunar Orbiting Platform GatewayIt 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.michelle@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) <mueller@kit.edu> wrote:
Hey John,
> > Anyone working on…
> Definitely not
Does that imply they're finished?
Best regards,
Marcus
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) <mueller@kit.edu> wrote:
Hey John,
> > Anyone working on…
> Definitely not
Does that imply they're finished?
Best regards,
Marcus
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 W5NYVOn Wed, Oct 30, 2019 at 7:14 AM Müller, Marcus (CEL) <mueller@kit.edu> wrote:Hey John,
> > Anyone working on…
> Definitely not
Does that imply they're finished?
Best regards,
Marcus
Hey John,
> > Anyone working on…
> Definitely not
Does that imply they're finished?
Best regards,
Marcus
Hi Madhuri - Please keep this discussion on the GR discussion list where it started: more people reading it increases the chances of someone providing help!Nobody here is going to provide you with the programs as you describe. This email discussion group is, broadly, about providing advice ... you have to do the actual work & ask specific enough questions to get reasonable feedback. You've provided some specifics now, and the best advice I can give is the following:If you look through GNU Radio examples, both from GR itself as well as "out of tree" (OOT) modules, you'll find some interesting GRC flowgraphs. None will do -everything- that you're looking out of the box, but you can piece together enough from various places to do what you want, plus or minus.Cheers! - MLD--On Tue, Oct 29, 2019 at 11:26 AM Madhuri Gummineni <madhuri.vijay2003@gmail.com> wrote:Dear sir,i have USRPN210 (UBX Daughterboard ) transceiver .If i (from one usrp)send any message say password is -23on the otherside the other usrp should decode it and verify it. if it is 23 then it has to hop from f1(96Mhz) to f2(98Mhz)Therefore it requires two programsTX side-grc flowgraph for sending messageprogram on RX side1) grc hopping flowgraph for Hopping2) grc flowgraph for decoding (for password verification)3)connecting 1) and 2) to implement it.Sir remaining parameters BW-75K, modulation -PSK .please guide me sirThank you sir
Anyone working on blocks specifically for Lunar Orbiting Platform Gateway? Or interested in doing so?-Michelle W5NYV---Michelle W5NYV"Potestatem obscuri lateris nescis."
Dear sir,i have USRPN210 (UBX Daughterboard ) transceiver .If i (from one usrp)send any message say password is -23on the otherside the other usrp should decode it and verify it. if it is 23 then it has to hop from f1(96Mhz) to f2(98Mhz)Therefore it requires two programsTX side-grc flowgraph for sending messageprogram on RX side1) grc hopping flowgraph for Hopping2) grc flowgraph for decoding (for password verification)3)connecting 1) and 2) to implement it.Sir remaining parameters BW-75K, modulation -PSK .please guide me sirThank you sir
Hi Miklos - Excellent! Thanks for sharing your work! - MLDOn Thu, Oct 17, 2019 at 9:02 PM Miklos Maroti <mmaroti@gmail.com> wrote:Dear Fellow GNURadio Users,
We are happy to announce that we are open sourcing the MarmotE modem
that we have developed for the DARPA Spectrum Collaboration Challenge
under the GPLv3 license at https://gitlab.com/marmote/gr-marmote3.
This is an FBMC based modem capable of using up to 40MHz of bandwidth
with a good computer, but can be used with a simple laptop with lower
sampling rates. There might be a few rough edges in the code base
specifically tailored for the Colosseum and SC2 challenge, but we have
created a simplified version of the modem that works with any USRP or
other SDR. The code base has lots of interesting components, including
good error correcting codes, SSE optimized fractional FBMC channelizer
and synthesizer, variable length packets, multiple MCS settings, ARQ,
TCP/UDP port based QoS settings, etc. We plan to write a manual, but
till then enjoy the short README, the raw code and the flow graphs.
Finally, please cheer for Team MarmotE on the DARPA SC2 championship
event at MWC Los Angeles 2019, October 23.
Best,
Miklos
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
hi,i am trying to write grc flow graph to switch(hop) from one frequency to other if it detects the password.if one usrp send a message as switch it should to other frequency.for this what are blocks that are required.planning like a remote operation to switch a sdr or usrp to switch or hop based on password.if one usrp send a message as password, then other usrp/sdr should hop if password is correct otherwise it will not hopplease help me sir
Is this the same baseband signals copied at several place ?
What you can do is :
* First modulate the signal to a narrow sample-rate (just enough for
the modulation)
* Upsample that signal to 1 Msps.
- Depending on the ration between the narrow rate and wide rate, it might be
beneficial to do that in several steps.
- So for instance you would go from 10 kHz to 100 kHz first with a
filter that's relatively sharp
- Then you would go from 100 kHz to 1 MHz with a second filter than
can be much more relaxed (i.e. larger transition bandwidth and so much
less CPU usage)
* Then use several rotators to position it at the various places you
need it in the 1MHz bandwidth
* And finally add the output of all the rotators.
There is also the so called Polyphase Filter Banks, but that only
works if you need carriers that are all equally spaced. And is also
only a benefic if you really fill a significant number of them.
" but my wi-fi packet receiver works just dandy without any OFDM blocks" --> Can you check the standard which your wifi receiver is following ? If it is 802.11b, then it wont work with gr-ieee 80211 because gr-ieee 80211 is based on OFDM based WiFi.You cannot use .pcap file as file source for the wifi_tx.grc.May I know your final aim for this experiment so that I can put my suggestions ?RegardsSumitOn Sun, 27 Oct 2019 at 20:10, Eamon Heaney <heaneye@vt.edu> wrote:Hi,I'm trying to create a wi-fi transmitter in GNURadio that can take a file source and transmit it as an 802.11 packet. I'm using this example as a basis, and trying to follow the guides here.Frankly, though, a lot of what's in that guide goes way over my head. I have a general understanding of what OFDM is, but my wi-fi packet receiver works just dandy without any OFDM blocks. So is it still necessary to incorporate such blocks into a transmitter?Secondly, I can't just plug a .pcap file source into the transmitter; it doesn't generate, and I get the feeling that .pcap isn't the proper format for transmission anyways. How can I figure out which blocks to put after the file source to make it gel with the next block in the example (WiFi MAC)?Thanks!
--Eamon HeaneyFleet CommanderPresident, Model UN at Virginia Tech--Sumit Kumar
Negativity always wins the short game. But positivity wins the long game. - Gary Vaynerchuk
On Oct 28, 2019, at 11:01 AM, Barry Duggan <barry@dcsmail.net> wrote:
Hi Markus,
From what I can tell, the PLL Carrier Tracking block does the correction, but it doesn't tell you what it did, so I'm not sure you can log the offsets. There are other PLL blocks I haven't looked at yet, so I don't know about them. See https://wiki.gnuradio.org/index.php/Category:Block_Docs for a list of all the blocks. Not all of them have been updated yet! That's what I am working on. Especially the example flowgraphs.
73
---
Barry Duggan KV4FV
On 2019-10-28 11:41, Markus Heller wrote:Dear OMs,I guess this carrier tracking block would be useful to handle frequencydrift of cheap (unstabilized) devices, when working QO-100 satelliteconnections. This block could be used to find the band end beacons andderive the frequency shift and correct it accordingly. Right?vy73markusdl8rdsAm Montag, den 28.10.2019, 09:44 -0500 schrieb Bill Dailey:Can you give a little primer on using that PLL tracking? I wouldlove to use that to just track carriers random frequencies. Forinstance 10mhz. Ultimately I want to track and periodically log andoffset from true predicted frequency. Like every 10 seconds.Bill DaileyNegativity always wins the short game. But positivity wins the longgame. - Gary VaynerchukDon't be easy to understand,Be impossible to misunderstand- Steve Sims> On Oct 28, 2019, at 9:27 AM, Barry Duggan <barry@dcsmail.net>> wrote:>> Hi Albin and Volker,>> I added a PLL Carrier Tracking block to take care of the tuning> problem. See the revised> https://wiki.gnuradio.org/index.php/File:FunCube_AM.png>> Albin, that 'spike' is the carrier! This is AM ;)>> Thank you both for your suggestions.> ---> Barry Duggan KV4FV>>> On 2019-10-27 07:13, Albin Stigö wrote:> > Hi Barry,> > Some thoughts:> > You have a large DC spike at the center, try using the frequency> > xlating> > fir filter to tune an offset frequency.> > Why don't you decimate at the channel filter?> > Try observing the signal at various points using the frequency> > sink.> > Good luck,> > Albin SM6WJM> > On Sat, Oct 26, 2019, 21:02 Barry Duggan <barry@dcsmail.net>> > wrote:> > > Hi,> > > I've been working on a gnuradio AM broadcast receiver, and have> > > found> > > that the tuning is very critical to obtaining clear audio. My> > > flowgraph> > > can be seen at> > > https://wiki.gnuradio.org/index.php/File:FunCube_AM.png.> > > Are there any alternate demodulation methods which are not so> > > sensitive> > > to exact tuning?> > > Thanks,> > > --> > > Barry Duggan KV4FV
