[Hackrf-dev] Analog TV Transmitter

[Iluta V]

Thanks, Karsten,

You expressed absolutely my thoughts, when you said that, please allow me
to cite again: "you may write your own firmware and your own library, for
any operating system you want".

I suspect that people demanding for them software and hardware be served on
a dining plate for Windows, out of 95% won't be able / willing to write a
code or two themselves. And out of those who can do it in Windows, will
have a heck of a good time to do it in open source as well. So either you
know both or know none.

My 10+ years in Aviation industry where a national airline was built from
ground up in all aspects have proved it to be like that and not otherwise.

Future is Open.

BR,

Iluta

On Tue, May 26, 2015 at 4:57 PM, Karsten von Hornbostel <
kaback at googlemail.com> wrote:

>
> First of all, hackrf has not been designed to be a complete
> transceiver, i guess. Think of it as some kind of exciter which covers
> a large frequency range. Filters, amplifiers and other features of
> complete transceivers may have to be implemented using additional
> (maybe external) components.
>
> The big advantage of HackRF over some of its competitors is, that the
> design is completely open source, software AND hardware.
>
> GNU Radio Companion (GRC) can be seen as a frontend for Gnu Radio, which
> enables users to "build" designs using flowgraphs. Its like building
> radios in the old days using breadborads and prototyping PCBs. This makes
> some
> stuff easier, not only for beginners. But sometimes it makes things
> harder to implement.
>
> If this is the case, GNU Radio (GR) may be your friend. Think of it as a
> library of some standard signal processing functions. This library
> exists for C/C++ and it brings python bindings.
>
> Hovever, if you want to implement something from ground up and if you
> need access to the raw samples, libhackrf may be your friend. It can
> be found at
>
> https://github.com/mossmann/hackrf/tree/master/host/libhackrf
>
> You may use GRC, but you dont have to. You may use GR, but you dont
> have to. You may use libhackrf, but you dont even have to, since the
> whole design is open soruce, you may write your own firmware and your
> own library, for any operating system you want.
>
>
>
> On Tue, May 26, 2015 at 12:17:34PM +0000, McDonald, J Douglas wrote:
> > As to analog TV, I bought the HackRF for that and have been unable to
> > do anything. The source code exists but is hopelessly impenetrable due
> > to the Gnu-ish style. I too would simply love to getpointers
> > on how to access the thing directly and not through the "companion".
> > I mean through a SIMPLE software interface, just calling subroutines
> > and getting callbacks from a timer to send packets. And of course
> > using Windows would be far better than Linux. But there seems
> > no way to do that.
> >
> > I want to emit 1950 field sequential (CBS) color and 1950 standard PAL
> and
> > PAF (phase alternating field)  color with a 3.89 MHz subcarrier as well
> > as variable field and frame rate B&W (And color too!) TV for 1920s and
> 30s sets
> >
> > I've essentially given up. But I'd love to get it working.
> >
> > The HackRF has such a bad internal passband filter that TV is always
> > going to have substantial images above and below the correct TV
> > signal, though well outside an ordinary receiver bandpass.
> >
> > Doug McDonald
> >
> > _______________________________________________
> > HackRF-dev mailing list
> > HackRF-dev at greatscottgadgets.com
> > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
> _______________________________________________
> HackRF-dev mailing list
> HackRF-dev at greatscottgadgets.com
> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20150526/1b5c8df4/attachment.html>