On Sun, 15 Sep 2013 02:26:44 -0400, rickman <gnuarm@gmail.com> wrote:

>On 9/14/2013 3:07 PM, Joerg wrote:
>> Piotr Wyderski wrote:
>>> rickman wrote:
>>>
>>>> When Piotr started talking about SDR he wasn't talking
>>>> about car radios anymore.
>>>
>>> Yes, something more like this class stuff:
>>>
>>> https://en.wikipedia.org/wiki/Joint_Tactical_Radio_System
>>>
>>
>> That's a whole different ballgame. When it comes to spread spectrum,
>> high frequency agility and similar traits it has to be SDR. But for
>> those guys cost (and to some extent power consumption) is not a concern.
>> Because the taxpayer foots the bill.
>
>Funny that you mention that cost doesn't matter because the "taxpayer" 
>is footing the bill.  I worked at a company making exactly those radios 
>and the engineering discussions would be about the safety of the 
>soldiers rather than "who cares, the tax payer is paying for it".  The 
>very best performance is demanded because there are many times when the 
>mission depends on it including lives.  But you are right in that cost 
>is not a primary factor.
>
>There is waste.  But mostly that comes from misdirected government 
>influences.  In the case of these radios the government wanted to "save 
>money" by reusing designs in multiple platforms.  But that usually meant 
>making the design more expensive to perform a wider mission with more 
>capabilities.  In the end it was a massive effort that may have saved 
>some money or may well have cost more than it saved.

Nonsense.  There is waste from top to bottom, some incompetence, some
because cost just isn't an important parameter, and yes, some because
the whole idea is just dumb.  Your admiration for the government's
forward thinking is cute, though.

On 9/14/2013 3:07 PM, Joerg wrote:
> Piotr Wyderski wrote:
>> rickman wrote:
>>
>>> When Piotr started talking about SDR he wasn't talking
>>> about car radios anymore.
>>
>> Yes, something more like this class stuff:
>>
>> https://en.wikipedia.org/wiki/Joint_Tactical_Radio_System
>>
>
> That's a whole different ballgame. When it comes to spread spectrum,
> high frequency agility and similar traits it has to be SDR. But for
> those guys cost (and to some extent power consumption) is not a concern.
> Because the taxpayer foots the bill.

Funny that you mention that cost doesn't matter because the "taxpayer" 
is footing the bill.  I worked at a company making exactly those radios 
and the engineering discussions would be about the safety of the 
soldiers rather than "who cares, the tax payer is paying for it".  The 
very best performance is demanded because there are many times when the 
mission depends on it including lives.  But you are right in that cost 
is not a primary factor.

There is waste.  But mostly that comes from misdirected government 
influences.  In the case of these radios the government wanted to "save 
money" by reusing designs in multiple platforms.  But that usually meant 
making the design more expensive to perform a wider mission with more 
capabilities.  In the end it was a massive effort that may have saved 
some money or may well have cost more than it saved.

-- 

Rick

Piotr Wyderski wrote:
> rickman wrote:
> 
>> When Piotr started talking about SDR he wasn't talking
>> about car radios anymore.
> 
> Yes, something more like this class stuff:
> 
> https://en.wikipedia.org/wiki/Joint_Tactical_Radio_System
> 

That's a whole different ballgame. When it comes to spread spectrum,
high frequency agility and similar traits it has to be SDR. But for
those guys cost (and to some extent power consumption) is not a concern.
Because the taxpayer foots the bill.

-- 
Regards, Joerg

http://www.analogconsultants.com/

Piotr Wyderski wrote:
> Joerg wrote:
> 
>> But wait, there's more. Blue blinkenlights, yellow blinkenlights.
> 
> Sure you need them! A friend of my brother produces and sells some
> simple ultrasound marten repelling devices. The sales went through
> the roof when he added a blinking LED to the box. So blinking is of
> crucial importance. :-)
> 

Oh yeah :-)


>> I never had much fun with SDR because it's expensive
> 
> You calculate costs differently when it's a hobby project.
> I.e. your time is basically free and the parts are expensive,
> which is exactly the oposite of professional prototyping.
> 

I am usually a cheapskate when it comes to hobby. Not because of budget
issues like I had when I was a kid but because I like finding a real
McGyver solution.


>> and generally inferior to the classic circuits when it comes to
>> performance.
> 
> Why should it be? The RF front-end is mostly the same.
> What is the difference between feeding an ADC and feeding
> an I/Q demodulator?
> 

My gear mostly has nice 8-pole crystal filters. Neither ADC nor I/Q
demodulator can (so far) touch that when it comes to large signal
handling. On shortwave the only fence between you and a plethora of
close-by noise is this filter.


>> I do now have one spectrum analyzer (the Signalhound) that is
>> basically an SDR.
> 
> I think most (or at least a significant fraction of) the modern
> radio receivers is a form of SDR. I mean the radios in the cell
> phones. You have a powerful CPU on board, often with DSP capabilities
> like the NEON instruction set, so all you need to do is to build
> a homodyne and move everything else to the digital domain. FM
> demodulation, stereo and RDS decoding -- all that is easy.
> All the PC TV USB dongles also work on this principle.
> 

Even modern ham radio gear is like that. Which is why I prefer the older
rigs.


> In my design I also moved the IF filtering to the FPGA.
> It was so much easier to build a digital filter with
> configurable passband than to do it the old school way...
> 

Well, head to the shortwave band on a very busy day and compare it to an
NRD-515, a Drake TR-7 or something similar. That's where the rubber
really meets the road.

-- 
Regards, Joerg

http://www.analogconsultants.com/

Stef wrote:
> In comp.arch.embedded,
> Joerg <invalid@invalid.invalid> wrote:
>> Stef wrote:
>>> In comp.arch.embedded,
>>> Joerg <invalid@invalid.invalid> wrote:
>>>> Stef wrote:

[...]

>>>>> In my experience, in medical device you can sometimes do changes without
>>>>> re-certification, but certainly not always. Thats why I started with "That
>>>>> is not always true". 
>>>>>
>>>> In the end the effort is mostly almost the same. In SW or firmware it's
>>>> regression testing et cetera. For safety boundary changes it's module
>>>> tests. And there it hardly makes a difference how much of it must be
>>>> re-tested.
>>> That's where I don't agree. If I change something in my software that
>>> is protected by hardware like in the above example. I can do my
>>> internal tests and write a document for the notified body. This 
>>> ofcourse takes time and care but it is much less work than a full
>>> re-certification effort. I don't need to repeat my safety tests, EMC
>>> tests etc.
>>>
>> You can take your chances but it carries risks. For example, I have seen
>> a system blowing EMC just because the driver software for the barcode
>> reader was changed. The reason turned out not to be the machine but the
>> barcode reader itself. One never knows.
> 
> Yes, there are always chances and you have to weigh the risks. Making
> sure all units pass EMC testing can only be done by fully testing each
> unit under all cirumstances. Which is ofcourse impossible.
> 

Some companies EMC-test every machine that leaves production though.


> Your barcode scanner example is unfortunate. But such a scanner could
> also change it's behaviour on scanning different codes and lighting
> conditions. Did you perform EMC testing with all available barcodes
> and forseeable lighting conditions?
> 

That usually isn't necessary. I told the client to get lots of different
new readers, and fast. They did that and it turned out that many that
were claimed as "class B" failed majorly. One didn't and it had so much
margin that it wasn't needed to test it under lots of conditions. I took
it apart to make sure that the designers had done a good job.

[...]

-- 
Regards, Joerg

http://www.analogconsultants.com/

On Fri, 13 Sep 2013 00:24:44 -0400, rickman <gnuarm@gmail.com> wrote:

>On 9/12/2013 5:42 PM, Joerg wrote:
>> rickman wrote:
>>> On 9/12/2013 1:03 PM, Joerg wrote:
>>>> Piotr Wyderski wrote:
>>>>> Joerg wrote:
>>>>>
>>>>>> Question: What do you do with an FPGA in a radio?
>>>>>
>>>>> As a matter of fact, it is one of the best places to use an FPGA. :-)
>>>>> SDR with FPGA reconfiguration capabilities is the ideal solution.
>>>>> Not for a regular FM noisemaker, though...
>>>>>
>>>>>       Best regards, Piotr
>>>>>
>>>>> *) It was exactly the only time in my life when I used an FPGA.
>>>>> + a 14-bit@65MHz Analog Devices ADC + 104 MHz DAC.
>>>>>
>>>>
>>>> It's going to be a tough sell for a radio. Even if they found one for $3
>>>> that's too much and they also can't stomach the 10sec to download the
>>>> compiled data in production.
>>>
>>> You really have no interest in learning anything about FPGAs that has
>>> happened in the last 10 or 15 years do you?
>>>
>>
>> Oh, I do. I just reviewed a design that has some rather fat ones in
>> there and it would hardly have been possible to do this without FPGA.
>> However, there are circuits where FPGAs are a perfect fit and others
>> where they just aren't. In ordinary radios they usually aren't.
>>
>>>
>>>> Everything has to fit into the $149.95 sale price at the auto parts
>>>> place, with fat profit margins for everyone and their middlemen,
>>>> speakers, wires, neon-colored huge window sticker, a discount coupon for
>>>> installation, free coffee and free waffles :-)
>>>
>>> You two are talking about totally different radios.
>>>
>>
>> The last few posts were about car radios, because the topic was
>> electronics and temperature exposure in cars.
>
>When Piotr started talking about SDR he wasn't talking about car radios 
>anymore.

He may not have been but (parts of) car radios are SDR.

On 9/13/2013 1:14 PM, Piotr Wyderski wrote:
> Piotr Wyderski wrote:
>
>  > The experience with mediaeval-quality Lattice software ~10 years
>> ago has considerably chilled my enthusiasm about the "alternatives".
>
> Sory, it was ACTEL, not Lattice, and the family was ProASIC with some
> number.

Ah yes, I've heard pro and con about the Actel software.

>>> The packages may not make you happy though. They seem to think
>>> the Smart Fusion chips need a bazillion I/Os.
>
> There is a TQFP144-variant of SmartFusion. But hear, hear!
> It's an improved and rebranded ProASIC3... :-D

Yes, similar.  There is the Smartfusion and the Smartfusion2.  I don't 
think the SF2 comes in any TQFPs.  The proASIC lines are so old I don't 
think I would design them into anything.  They are available in 100 pin 
QFPs though.

-- 

Rick

On 9/13/2013 12:43 PM, Piotr Wyderski wrote:
> rickman wrote:
>
>> I don't see how your personal memory has much to do with it. Most
>> programmers use
>> the tools, meaning HHL compilers. The main point of using an HLL is to
>> *not* need to know anything about the instruction set. If you can't
>> write HLL code for the specific CPU involved, then you have other issues.
>
> Rickman, professionally I am a low-level programmer. I mostly do
> weird optimizations, often at the assembly level. Can read assembly
> output generated by a compiler for several ISAs without any problem.
> Everyone is smart when things go right. When something fails, without
> that knowledge you are like a child in the fog. Please, do not teach
> me my craft. :-)

I won't teach you anything if you don't want to learn.

>>> In my case it's PCB routing complexity. I am not going
>>> to use 4+ layers of copper just to satisfy the monster's
>>> signal integrity requirements. 2 layers is all I can have.
>>
>> Uh, what monster???
>
> A great big FPGA chip which package imposes crazy
> (for a hobbyist) PCB routing requirements.

You mean like a 100 pin quad flat pack?  Are you even trying to look at 
possibilities?  This is the sort of bias about FPGAs that I keep running 
into.  Here is a board I make with an FPGA, a CODEC, some buffering and 
analog drivers.

http://arius.com/images/IRIGB_board_1-0.png

The board is 0.85" x 4.5".  An MCU could not provide the SPI "like" 
control interface from the motherboard and it would have been *very* 
hard to generate the clock timing for the CODEC which in one mode has to 
be slaved to the incoming data rate on an RS-422 interface.

>> I'm not sure that is impossible on an MCU. Maybe it is impossible on an
>> MCU you can buy, but a custom design might do nicely.
>
> Rickman, please... ;-)

Please what?

Is it possible that you aren't aware of all CPUs out there?

>> But since you can have so many CPUs on even a smallish FPGA, I expect
>> you could
>> divide and conquer quite easily.
>
> But what for? A PWM generator is a no-brainer in VHDL. One can also
> stream out the content of a BRAM in a loop directly to the IO pins,
> which allows one to implement fancy spectrum spreading techniques,
> equalize the amount of power consumed by shifting the relative
> phases of the PWM channels, etc. One BRAM = 18 channels. Cheap. :-)
> And a CPU to generate the actual waveforms off-line, even a tiny one.

But something has to control the PWM.  So if you have software 
controlling the PWM you have to decide how much is in software and how 
much is in hardware.  I don't know your requirements so I can't speak as 
to where the optimal trade off point would be.

>> You can wave the same hands for CPU cycles. The only difference is MCU
>> I/Os are not as flexible, typically being constrained to one set of pins
>> or a small selection of I/Os. I guess that was your point?
>
> More or less. I wanted to highlight that a CPU has e.g. a timer input
> with input capture timestamping connected to a dedicated pin. When the
> PCB is etched and you discover that connecting another pin to that input
> capture allows you to do something smart, you have a problem. In case
> of an FPGA you just provide an additional internal "wire" in the
> routing section and presto, problem solved.
>
>> If your designs are so slow that isn't an issue, fine, but that
>> is not very common.
>
> If it is necessary, I can use a dedicated pin. But I don't use
> those multi-gigabit transceivers etc., so, except of the clock,
> a generic IO pin is fine for most of my signals.

You are thinking of SERDES which are specialized functions...  because 
they are impossible to do in the FPGA fabric.  But dedicated clock pins 
have been around almost since the beginning of FPGAs.

>> Check out the GA144 from greenarrays.com.
>
> I've checked that years ago and it still is in the mental bin
> labelled "bizarre". It is neither a CPU, nor an FPGA, gracefully
> merging disadvantages of both. :-)

It does have its limitations, I agree.  But is has some great features. 
  I would use it to redo the board in the image above but I don't have 
enough confidence in the survival of the company.  The redo is because 
of one of the very few EOL notices on an FPGA that I just happen to be 
using.  The GA144 could do the job pretty well I think.

>>> The toolchain is mature.
>>
>> How mature do you need?
>
> The so-called industrial quality. As seen in case of
> x86/ARM/PowerPC/SPARC and maybe MIPS.

I don't know what "industrial quality" is.  I think the tools for the 
microBlaze, the NIOS, NIOS2, etc are all widely used and well debugged. 
  Have you heard any complaints?

>> Then don't use a Cyclone/Spartan part...
>
> That's complicated. First of all, I (would) use an FPGA I can
> easily buy in smal quantities. Secondly, I know the toolchain.
> The experience with mediaeval-quality Lattice software ~10 years
> ago has considerably chilled my enthusiasm about the "alternatives".

The project I give the image for above uses a Lattice part and I had no 
trouble with the tools.  We all have our biases.

>> The packages may not make you happy though. They seem to think
>> the Smart Fusion chips need a bazillion I/Os.
>
> TQFP is the only package I can handle. But will have a look,
> just to learn something new.

Then I think you are out of luck with the SmartFusion.  The GA144 is 
available on a mounting board from Schmartboard.  They sent me one of 
the boards without the chip.  Interesting.  They route the top layer of 
fiberglass down to an inner copper layer and drop a bead of solder in 
it.  I think the idea is to work with leaded parts like the QFP, but 
they say it works with leadless parts too.  Essentially the PCB forms a 
one or two mm high solder mask and the solder acts like a heat pipe to 
allow connection to QFN pins on the underside of the chip.

http://blog.schmartboard.com/blogschmartboard/2013/09/greenarrays-month-at-schmartboardand-you-can-try-it-save-some-green.html

-- 

Rick