> Posted August 15th, 2013:
> https://9p.io/sources/contrib/stallion/src/sdmpt2.c Corresponding
> announcement:
> https://groups.google.com/forum/#!topic/comp.os.plan9/134-YyYnfbQ
This is not a NVMe driver.
--
Aram Hăvărneanu
Hi Steven,
Could you please tell me how to subscribe from this EMAIL LIST.
I don't have the time,or my own computer,to find the Webpage.
Today i have nearly 20 messages from the PLAN 9 LIST.
I am also getting a lot from the HAIKU LIST.
Many thanks,
Dhan Hurley
DIASPORA COMMUNITY,MY PROFILE PAGE :-
hiro writes:
> Does this include demodulation on the pi?
Yes. At least to a certain extent. The idea is to get from the
high-birate I/Q data so something more amenable to transmission
over an RS-422 (or -485) serial drop.
One example is for an AIS transceiver on a boat. By putting the
radio a
> I have been able to copy 1 GiB/s to userspace from an nvme device. I should
> think a radio should be no problem.
The problem is when you have multiple decoder blocks implemented
as individual processes (i.e. the GNU radio model). Once you have
everything debugged, you can put it into a single
On Thu, Oct 11, 2018 at 10:54:22AM -0700, Lyndon Nerenberg wrote:
>
> Since when did curiosity become a capital crime? Oh, wait, that
> was January 20, 2017. My bad.
Turns out it's not, so you can climb down off your cross. It's just
that it helps to be a little clearer about your meaning, tha
Digby R.S. Tarvin writes:
> Agreed, but the PDP11/70 was not constrained to 64KB memory either.
> I do recall the MS-DOS small/large/medium etc models that used the
> segmentation in various ways to mitigate the limitations of being a 16 bit
> computer. Similar techniques were possible on the PDP
> One example is for an AIS transceiver on a boat. By putting the
> radio and decoder at the top of the mast, the backhaul can be a
> cat-3 twisted pair cable, rather than a much heavier coax run from
> the antenna at the top of the mast to the receiver below decks.
Yeah, I've been sending 3Mbit
> through the kernel. Not so much for the speed aspect, but to free
> up CPU cycles that can be devoted to actual SDR work.
those 2x25kHz channels would hardly need many cycles. rather it's just
a matter of selecting the right CPU that can actually do the FFT with
some software floating point imp
i meant without having to resort to some soft fp.
On 10/11/18, hiro <23h...@gmail.com> wrote:
>> through the kernel. Not so much for the speed aspect, but to free
>> up CPU cycles that can be devoted to actual SDR work.
>
> those 2x25kHz channels would hardly need many cycles. rather it's just
>
We also have CPU extensions that can help make fast FFT, because it's
such a generic problem, and in the worst case you can use fpgas,
asics, in any case dedicated hardware.
I was able to use dump1090 (same author as redis) to get ADSB data reliably
on RPi/Linux a while back.
On Thu, Oct 11, 2018, 10:54 AM Lyndon Nerenberg wrote:
> > I have been able to copy 1 GiB/s to userspace from an nvme device. I
> should
> > think a radio should be no problem.
>
> The problem
hiro writes:
> But given the alternatives available back then, even the armv5 in the
> kirkwood, which was cheaper even before the rpi became popular, did
> the same job more stably, which is why i would never actually
> recommend the pi. And there are even more alternatives now.
I get that. But
> I was able to use dump1090 (same author as redis) to get ADSB data reliably
> on RPi/Linux a while back.
I have a pair of Flightbox ADS-B receivers I am using as references.
While mostly reliable, they can and do stutter along with the rest
of the alternatives on occasion.
--lyndon
I assumed you were using an RTL2832U (rtlsdr library).
On Thu, Oct 11, 2018, 12:40 PM Lyndon Nerenberg wrote:
> > I was able to use dump1090 (same author as redis) to get ADSB data
> reliably
> > on RPi/Linux a while back.
>
> I have a pair of Flightbox ADS-B receivers I am using as references.
Skip Tavakkolian writes:
> I assumed you were using an RTL2832U (rtlsdr library).
I'm pretty sure they all do, under the hood.
> need to prove it can be done with the usual
> suspects (GNU radio, on the Pi -- the native fft libraries seem fast
> enought to make this viable).
be assured i've demodulated 25khz signals in real-time and it's a walk
in the park, as long as your revision has the neon stuff i mentioned,
otherwis
>> I assumed you were using an RTL2832U (rtlsdr library).
>
> I'm pretty sure they all do, under the hood.
>
>
don't you need sending ability, too for AIS?
hiro writes:
> don't you need sending ability, too for AIS?
No, a receive-only setup is very useful on a small boat. Where I
would like to go with this is to take the decoded AIS data as input
for "ARPA" style collision plots. I'm interested in the big boats
sailing through the straight. They
Another case to ponder ... We're handling the incoming I/Q data
stream, but need to fan that out to many downstream consumers. If
we already read the data into a page, then flip it to the first
consumer, is there a benefit to adding a reference counter to that
read-only page and leaving the page
Oh yes, I read Eldon Halls book on that quite a few years ago. Meetings
held to discuss competing potential uses for a word of memory that had
become free.
That one would be a challenging Plan9 port..
On Fri, 12 Oct 2018 at 05:13, Lyndon Nerenberg wrote:
> Digby R.S. Tarvin writes:
>
> > Agreed
Digby R.S. Tarvin writes:
> Oh yes, I read Eldon Halls book on that quite a few years ago. Meetings
> held to discuss competing potential uses for a word of memory that had
> become free.
> That one would be a challenging Plan9 port..
And yet Plan9 was not there to save the day. Such a pity.
i'm not saying you should measure a lot even. just trying to make you
verify my point that this is not your bottleneck, just check if you
hit a cpu limit already with that single processing stage (my guess
was FFT).
the reason why i think my guess is right is bec. of experience with
the low bandwi
On 10/11/18, hiro <23h...@gmail.com> wrote:
>
> [ ... ] which is why i would never actually
> recommend the pi. And there are even more alternatives now.
>
Simply because I've never seen their name mentioned here - I did miss
a year or two, I'm sure I mentioned them before that - let me do same
nam
On Thu, 11 Oct 2018 13:43:00 -0700, Lyndon Nerenberg wrote:
> Another case to ponder ... We're handling the incoming I/Q data
> stream, but need to fan that out to many downstream consumers. If
> we already read the data into a page, then flip it to the first
> consumer, is there a benefit to
24 matches
Mail list logo
