Re: [Discuss-gnuradio] power amplifiers on TX
Output power of an SDR is both a function of gain and of course of the digital signal you're generating - for example, a digital signal with amplitude 0.5 should have, in theory, 25 times the power of the same scaled to have an amplitude of 0.1. Best regards, Marcus Am 30. Dezember 2015 22:43:04 MEZ, schrieb Daniel Pocock : > > >On 30/12/15 22:24, Marcus Müller wrote: >> Hi Daniel, >> Cannot stress this enough: >> Don't try to do everything to the max right from the start. Sure, >100mW >> is a lot less than what can do in the licensed bands, but then again, >> not coming from an amateur background, 120W right out scare me. >Please > >Maybe some clarification is in order: > >- need to check if the power amp's output is proportionate to the input >power > >- does the USRP and GNU Radio provide a way to manage output power >(power into the amp), or is it always constant at 100 mW? > >- it is legal - e.g. 400W is the limit in the UK and regs are similar >in >other countries for fully licensed hams: >http://www.ofcom.org.uk/static/archive/ra/publication/ra_info/br68r11/br68.htm > >> make sure no more than -15dBm are fed into the USRP RX. So at an >output >> power of 120 W ~= 51dBm, you need isolation of at least 66dB between >> your TX antenna and the RX port of your USRP for the TX frequency. >Also, >> considering you're buying a device that can potentially cover 70MHz >to >> 6GHz, spending lots of money on a powerful amplifier that can but >> operate on a few MHz really sounds like an unbalanced investment. >Maybe >> reduce the output power (unless you want to do moon bounce, maybe), >and >> get separate filters, just to keep the option of not operating in >> 144-147MHz; your whole operational range is much smaller than the >amount >> of spectrum you can control with the USRP at once. >> > >Agreed - many people would be satisfied with something up to 50W, >similar to a mobile rig, this was just the first thing Google found >when >I included "100 mW" in my search query. > >I have had SAREX contacts with 5W from a handheld device and J-pole, >but >that was in Australia where the population is very thinly distributed >and I could have been the only person transmitting. There were no >nearby mountains (unlike my current QTH) and no tall buildings. In a >densely populated region like Europe, more power may appeal to some >people. > >> Of you're not going to use two highly directive antennas for RX and >TX >> to achieve isolation: >> You will either need an RX/TX switch (that you should definitely >control >> using the USRPs GPIO pins, which can be programmed to certain states >> when transmitting, receiving or doing full duplex) to isolate RX from >TX >> when transmitting, or an extremely expensive circulator-based device. >> >> To be honest, you seem to be throwing money at your problem, that >partly >> including having a bit of uncertainty what you want to do. I'd rather >> start small, buy the USRP, and maybe a preselective filter, >experiment a >> bit with "short links", then invest in antennas, filters, switches >and >> or amplifiers as you build up wishes and experience. >> My feeling is that you'd probably want to first RX only on different >> bands with different antennas, see what's possible with and without >> preselection, then decide on one or two bands, get more specific >filters >> for these, switches, and then an amp. >> Don't start with something that you can use to defrost your antenna, >and >> then try to figure out where you fried which parts of your rig. > >Thanks for this feedback, I wasn't going to go out and buy this first, >I >just wanted to start putting together a vision of what the big picture >looks like and what all the pieces will cost. > >Buying an amp that can fry an egg is a poor substitute for having the >right antenna. On the receive side, this fact is obviously even more >unavoidable. > >Regards, > >Daniel -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] power amplifiers on TX
Hi Ron, Michael Kuhne DB6NT started with HAM products a few decades ago. They were so good in quality that they were used by commercial customers. So he set up his company. Today he makes his money with commercial customers bus has not forgotten his roots. DB6NT is really cool. And he's also open for discussions and good ideas from the HAM domain. I once had a chat with him about a WIFI transverter from the 13cm band into higher GHz bands. So if you need something special, I do advise you to simply contact him. Even in face he does not have an according product for you, he might help you with ideas and hints nevertheless. vy73 markus dl8rds Am Mittwoch, den 30.12.2015, 16:53 -0800 schrieb Ron Economos: > In Canada, you can use up to 2250 watts PEP output on SSB. > > http://www.ic.gc.ca/eic/site/smt-gst.nsf/eng/sf01226.html#p10.2 > > In the US, it's 1500 watts PEP output in any mode. > > The Kuhne Electronic equipment is excellent stuff. It's essentially > commercial equipment that's been re-purposed for the ham bands. In fact, > as a licensed operator, you can purchase their industrial products. For > example, I'm using this amplifier for 70cm digital television. > > http://shop.kuhne-electronic.de/kuhne/en/shop/industrial/prof-power-amplifier/KU+PA+04105025+A++UHF+MOSFETPower+Amplifier/?card=413 > > However, due to the high PAPR of digital waveforms, it only delivers a > few watts of average linear power. > > Ron > > On 12/30/2015 04:26 PM, Kevin McQuiggin wrote: > > The amateur limit is 1000 Watts. Personally I ran 800+ Watts on the 2 > > metre band in the late 1980s for my EME (moonbounce) station. All > > analog, single long-boom Yagi. I used a 2M downconverter and listened > > on my 10M receiver as it was way more sensitive than my 2M rig. > > > > Over about a year's operation I heard about 10 stations via EME and > > worked only 2. Still, that was a very good operational record for a > > single Yagi station of the era. > > > > Possibly relevant to Marcus' and others' warnings, my power amplifier > > did EXPLODE on one occasion due to dried-out filter capacitors. Big > > fireball, and little bits of paper blown right through the amplifier > > case and all over the room. It was spectacular :=/ > > > > My wife tells the story very well: she was in the kitchen and heard this > > big "BOOM". She called upstairs "Is everything alright?" and I calmly > > replied "No problem. Could you bring the fire extinguisher up here please?" > > > > Fortunately no fire, and I replaced the filter capacitors. The > > amplifier was fine - a good bonus, as I had borrowed it from a research > > lab at a local university for a couple of weeks. > > > > With the new weak signal DSP techniques, I hear that 100 Watts and a > > single Yagi will get you many contacts, although the data rate will be > > very low. Still, it works and that is amazing! > > > > I think Daniel was just asking if these German amplifiers are good > > quality. I hear that they are, and that they work very well, although I > > have never used or seen one in person. I hear they stand behind their > > gear, and will also do custom designs. > > > > Kevin (VE7ZD) > > > > > > On 15-12-30 04:03 PM, Johnathan Corgan wrote: > >> On Wed, Dec 30, 2015 at 3:14 PM, James Humphries > >> mailto:james.humphr...@ettus.com>> wrote: > >> > >> > >> I'm on Marcus' side with that output power, that's a scary high > >> output. I start to sweat at 10W... :) > >> > >> > >> Heh, I connected a USRP to a 20KW PA once. Sweating was only one of > >> several things done in anticipation :) > >> > >> > >> -- > >> Johnathan Corgan > >> Corgan Labs - SDR Training and Development Services > >> http://corganlabs.com > >> > >> > >> ___ > >> > > > ___ > 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
Re: [Discuss-gnuradio] Working with Tags
On Wed, Dec 30, 2015 at 3:32 PM, wrote:
> It’s a tag generator that goes through several other blocks before getting
> to the tag receiver.
>
>
>
> tag generator - mag^2 - moving average --- divide - add
> constant - tag receiver
>
>\- moving average -/
>
>
>
> Basically I’m computing the ration of a fast average to a slow average and
> sending that to a threshold detector sink (tag receiver) to watch for the
> signal to go above threshold. It then sends a message with the time stamp
> of that event to another block for other processing. I wrote the tag
> generator and tag receiver.
>
>
>
> Mark.
>
>
I'd recommend plugging the tag generator directly into the tag receiver
just to make sure both of those are handling the tags properly. If they
are, then we can dive into the rest of the chain to see where things might
be having problems. My guess is that it'll be related to the different
delays of the moving average filters.
This also might be related to a bug that we recently patched:
https://github.com/gnuradio/gnuradio/commit/ae2e24f86b562a5bdcb9f5170e0abb1cd15838cf
Tom
>
>
> *From:* trond...@trondeau.com [mailto:trond...@trondeau.com] *On Behalf
> Of *Tom Rondeau
> *Sent:* Wednesday, December 30, 2015 9:36 AM
> *To:* Christiansen, Mark W. @ CSG - CSW
> *Cc:* GNURadio Discussion List
> *Subject:* Re: [Discuss-gnuradio] Working with Tags
>
>
>
> On Wed, Dec 30, 2015 at 11:15 AM, wrote:
>
> I wrote a block that writes the rx_time tag and another block that reads
> it. After reading them for a 20 to thirty calls to the work function, it
> stops getting any. The amount it reads varies from run to run. Any ideas?
>
> This code snippet is from the work function my block that writes the tag.
> The cerr statement continues to print to the console until I stop execution.
>
>
>
>
>
> VITA49_packet_info packet_info = p_packet->get_VITA49_packet_info();
>
> if (m_do_send_tags)
>
> {
>
> double timestamp_in_seconds =
>
> static_cast(p_packet->get_integer_seconds()) +
>
> static_cast(p_packet->get_fraction_seconds()) * 1e-12;
>
> const pmt::pmt_t timestamp = pmt::make_tuple(
>
> pmt::from_uint64(static_cast long>(floor(timestamp_in_seconds))),
>
> pmt::from_double(timestamp_in_seconds -
> floor(timestamp_in_seconds)));
>
> std::cerr << "SEND (" << d_id << ") "
>
> << " tag_offset=" << m_tag_offset
>
> << std::setprecision(std::numeric_limits::digits10
> + 1)
>
> << " timesamp_in_seconds=" << timestamp_in_seconds <<
> std::endl;
>
> add_item_tag(0, m_tag_offset, TIME_KEY, timestamp, d_id);
>
>
>
>
>
>
>
> How are you setting m_tag_offset?
>
>
>
>
>
> This code snippet is from my work function in the block that reads the
> tag. The cerr statement stops printing after twenty to thirty times
> suggesting that it no longer sees the time tags. The rest of the work
> function continues to operate properly.
>
>
>
>
> static const pmt::pmt_t TIME_KEY = pmt::string_to_symbol("rx_time");
>
> std::vector tags;
>
> get_tags_in_range(
>
> tags, 0, nitems_read(0), nitems_read(0) + noutput_items);
>
> std::vector::iterator itr;
>
> size_t j = 0;
>
> for (itr = tags.begin(); itr != tags.end(); itr++, j++)
>
> {
>
> if (pmt::eq((*itr).key, TIME_KEY))
>
> {
>
> d_real_time_seconds =
>
> static_cast(pmt::to_uint64(pmt::tuple_ref((*itr).value,
> 0))) +
>
> static_cast(pmt::to_double(pmt::tuple_ref((*itr).value,
> 1)));
>
> std::cerr << "RECEIVE (" << d_id << ") " << j
>
> << " tag_offset=" << (*itr).offset
>
> << " noutput_items=" << noutput_items
>
> << std::setprecision(std::numeric_limits::digits10
> + 1)
>
> << " time_seconds=" << d_real_time_seconds << std::endl;
>
> }
>
> }
>
> }
>
>
>
>
>
> /\/\ark.
>
>
>
>
>
> What does your flowgraph look like? Or is it just the tag producing block
> going straight in to the tag getter block?
>
>
>
> Tom
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Working with Tags
I'm gonna check this out. I may have fixed this according to the tests we
were looking at, but introduced a bug elsewhere.
A QA test involving the moving average blocks and stream tags might help
clear things up.
On Thu, Dec 31, 2015 at 10:38 AM, Tom Rondeau wrote:
> On Wed, Dec 30, 2015 at 3:32 PM, wrote:
>
>> It’s a tag generator that goes through several other blocks before
>> getting to the tag receiver.
>>
>>
>>
>> tag generator - mag^2 - moving average --- divide - add
>> constant - tag receiver
>>
>>\- moving average -/
>>
>>
>>
>> Basically I’m computing the ration of a fast average to a slow average
>> and sending that to a threshold detector sink (tag receiver) to watch for
>> the signal to go above threshold. It then sends a message with the time
>> stamp of that event to another block for other processing. I wrote the tag
>> generator and tag receiver.
>>
>>
>>
>> Mark.
>>
>>
>
> I'd recommend plugging the tag generator directly into the tag receiver
> just to make sure both of those are handling the tags properly. If they
> are, then we can dive into the rest of the chain to see where things might
> be having problems. My guess is that it'll be related to the different
> delays of the moving average filters.
>
> This also might be related to a bug that we recently patched:
>
> https://github.com/gnuradio/gnuradio/commit/ae2e24f86b562a5bdcb9f5170e0abb1cd15838cf
>
> Tom
>
>
>
>
>>
>>
>> *From:* trond...@trondeau.com [mailto:trond...@trondeau.com] *On Behalf
>> Of *Tom Rondeau
>> *Sent:* Wednesday, December 30, 2015 9:36 AM
>> *To:* Christiansen, Mark W. @ CSG - CSW
>> *Cc:* GNURadio Discussion List
>> *Subject:* Re: [Discuss-gnuradio] Working with Tags
>>
>>
>>
>> On Wed, Dec 30, 2015 at 11:15 AM, wrote:
>>
>> I wrote a block that writes the rx_time tag and another block that reads
>> it. After reading them for a 20 to thirty calls to the work function, it
>> stops getting any. The amount it reads varies from run to run. Any ideas?
>>
>> This code snippet is from the work function my block that writes the tag.
>> The cerr statement continues to print to the console until I stop execution.
>>
>>
>>
>>
>>
>> VITA49_packet_info packet_info = p_packet->get_VITA49_packet_info();
>>
>> if (m_do_send_tags)
>>
>> {
>>
>> double timestamp_in_seconds =
>>
>> static_cast(p_packet->get_integer_seconds()) +
>>
>> static_cast(p_packet->get_fraction_seconds()) * 1e-12;
>>
>> const pmt::pmt_t timestamp = pmt::make_tuple(
>>
>> pmt::from_uint64(static_cast> long>(floor(timestamp_in_seconds))),
>>
>> pmt::from_double(timestamp_in_seconds -
>> floor(timestamp_in_seconds)));
>>
>> std::cerr << "SEND (" << d_id << ") "
>>
>> << " tag_offset=" << m_tag_offset
>>
>> <<
>> std::setprecision(std::numeric_limits::digits10 + 1)
>>
>> << " timesamp_in_seconds=" << timestamp_in_seconds <<
>> std::endl;
>>
>> add_item_tag(0, m_tag_offset, TIME_KEY, timestamp, d_id);
>>
>>
>>
>>
>>
>>
>>
>> How are you setting m_tag_offset?
>>
>>
>>
>>
>>
>> This code snippet is from my work function in the block that reads the
>> tag. The cerr statement stops printing after twenty to thirty times
>> suggesting that it no longer sees the time tags. The rest of the work
>> function continues to operate properly.
>>
>>
>>
>>
>> static const pmt::pmt_t TIME_KEY = pmt::string_to_symbol("rx_time");
>>
>> std::vector tags;
>>
>> get_tags_in_range(
>>
>> tags, 0, nitems_read(0), nitems_read(0) + noutput_items);
>>
>> std::vector::iterator itr;
>>
>> size_t j = 0;
>>
>> for (itr = tags.begin(); itr != tags.end(); itr++, j++)
>>
>> {
>>
>> if (pmt::eq((*itr).key, TIME_KEY))
>>
>> {
>>
>> d_real_time_seconds =
>>
>> static_cast(pmt::to_uint64(pmt::tuple_ref((*itr).value,
>> 0))) +
>>
>> static_cast(pmt::to_double(pmt::tuple_ref((*itr).value,
>> 1)));
>>
>> std::cerr << "RECEIVE (" << d_id << ") " << j
>>
>> << " tag_offset=" << (*itr).offset
>>
>> << " noutput_items=" << noutput_items
>>
>> <<
>> std::setprecision(std::numeric_limits::digits10 + 1)
>>
>> << " time_seconds=" << d_real_time_seconds << std::endl;
>>
>> }
>>
>> }
>>
>> }
>>
>>
>>
>>
>>
>> /\/\ark.
>>
>>
>>
>>
>>
>> What does your flowgraph look like? Or is it just the tag producing block
>> going straight in to the tag getter block?
>>
>>
>>
>> Tom
>>
>>
>>
>
>
> ___
> 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
Re: [Discuss-gnuradio] Working with Tags
Weird. I don't see a problem between strobe_tags -> moving average ->
vector sink with my test. How is m_tag_offset getting set?
On Thu, Dec 31, 2015 at 7:43 PM, Paul David wrote:
> I'm gonna check this out. I may have fixed this according to the tests we
> were looking at, but introduced a bug elsewhere.
> A QA test involving the moving average blocks and stream tags might help
> clear things up.
>
> On Thu, Dec 31, 2015 at 10:38 AM, Tom Rondeau wrote:
>
>> On Wed, Dec 30, 2015 at 3:32 PM, wrote:
>>
>>> It’s a tag generator that goes through several other blocks before
>>> getting to the tag receiver.
>>>
>>>
>>>
>>> tag generator - mag^2 - moving average --- divide - add
>>> constant - tag receiver
>>>
>>>\- moving average -/
>>>
>>>
>>>
>>> Basically I’m computing the ration of a fast average to a slow average
>>> and sending that to a threshold detector sink (tag receiver) to watch for
>>> the signal to go above threshold. It then sends a message with the time
>>> stamp of that event to another block for other processing. I wrote the tag
>>> generator and tag receiver.
>>>
>>>
>>>
>>> Mark.
>>>
>>>
>>
>> I'd recommend plugging the tag generator directly into the tag receiver
>> just to make sure both of those are handling the tags properly. If they
>> are, then we can dive into the rest of the chain to see where things might
>> be having problems. My guess is that it'll be related to the different
>> delays of the moving average filters.
>>
>> This also might be related to a bug that we recently patched:
>>
>> https://github.com/gnuradio/gnuradio/commit/ae2e24f86b562a5bdcb9f5170e0abb1cd15838cf
>>
>> Tom
>>
>>
>>
>>
>>>
>>>
>>> *From:* trond...@trondeau.com [mailto:trond...@trondeau.com] *On Behalf
>>> Of *Tom Rondeau
>>> *Sent:* Wednesday, December 30, 2015 9:36 AM
>>> *To:* Christiansen, Mark W. @ CSG - CSW
>>> *Cc:* GNURadio Discussion List
>>> *Subject:* Re: [Discuss-gnuradio] Working with Tags
>>>
>>>
>>>
>>> On Wed, Dec 30, 2015 at 11:15 AM,
>>> wrote:
>>>
>>> I wrote a block that writes the rx_time tag and another block that reads
>>> it. After reading them for a 20 to thirty calls to the work function, it
>>> stops getting any. The amount it reads varies from run to run. Any ideas?
>>>
>>> This code snippet is from the work function my block that writes the
>>> tag. The cerr statement continues to print to the console until I stop
>>> execution.
>>>
>>>
>>>
>>>
>>>
>>> VITA49_packet_info packet_info = p_packet->get_VITA49_packet_info();
>>>
>>> if (m_do_send_tags)
>>>
>>> {
>>>
>>> double timestamp_in_seconds =
>>>
>>> static_cast(p_packet->get_integer_seconds()) +
>>>
>>> static_cast(p_packet->get_fraction_seconds()) * 1e-12;
>>>
>>> const pmt::pmt_t timestamp = pmt::make_tuple(
>>>
>>> pmt::from_uint64(static_cast>> long>(floor(timestamp_in_seconds))),
>>>
>>> pmt::from_double(timestamp_in_seconds -
>>> floor(timestamp_in_seconds)));
>>>
>>> std::cerr << "SEND (" << d_id << ") "
>>>
>>> << " tag_offset=" << m_tag_offset
>>>
>>> <<
>>> std::setprecision(std::numeric_limits::digits10 + 1)
>>>
>>> << " timesamp_in_seconds=" << timestamp_in_seconds <<
>>> std::endl;
>>>
>>> add_item_tag(0, m_tag_offset, TIME_KEY, timestamp, d_id);
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> How are you setting m_tag_offset?
>>>
>>>
>>>
>>>
>>>
>>> This code snippet is from my work function in the block that reads the
>>> tag. The cerr statement stops printing after twenty to thirty times
>>> suggesting that it no longer sees the time tags. The rest of the work
>>> function continues to operate properly.
>>>
>>>
>>>
>>>
>>> static const pmt::pmt_t TIME_KEY = pmt::string_to_symbol("rx_time");
>>>
>>> std::vector tags;
>>>
>>> get_tags_in_range(
>>>
>>> tags, 0, nitems_read(0), nitems_read(0) + noutput_items);
>>>
>>> std::vector::iterator itr;
>>>
>>> size_t j = 0;
>>>
>>> for (itr = tags.begin(); itr != tags.end(); itr++, j++)
>>>
>>> {
>>>
>>> if (pmt::eq((*itr).key, TIME_KEY))
>>>
>>> {
>>>
>>> d_real_time_seconds =
>>>
>>>
>>> static_cast(pmt::to_uint64(pmt::tuple_ref((*itr).value, 0))) +
>>>
>>>
>>> static_cast(pmt::to_double(pmt::tuple_ref((*itr).value, 1)));
>>>
>>> std::cerr << "RECEIVE (" << d_id << ") " << j
>>>
>>> << " tag_offset=" << (*itr).offset
>>>
>>> << " noutput_items=" << noutput_items
>>>
>>> <<
>>> std::setprecision(std::numeric_limits::digits10 + 1)
>>>
>>> << " time_seconds=" << d_real_time_seconds << std::endl;
>>>
>>> }
>>>
>>> }
>>>
>>> }
>>>
>>>
>>>
>>>
>>>
>>> /\/\ark.
>>>
>>>
>>>
>>>
>>>
>>> What does your flowgraph look like? Or is it just the tag producing
>>> block going straight in to the tag getter block?
>>>
>>>
>>>
>>> Tom
>>>
>>>
>>>
>>
>>
>> ___
>> Dis
[Discuss-gnuradio] Hackfest Berlin
Hi everyone, quick reminder we'll be doing a hackfest in Berlin. Infos can be found here: http://gnuradio.org/redmine/projects/gnuradio/wiki/Hackfest1601 The hackfest is the last week of January (25.-28.), with time left to travel to Brussels for FOSDEM! If you're interested in coming, please contact me off list. Note that you don't have to be a GNU Radio pro to attend, interest in the project is enough! Cheers, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
