<muurkha>
(transmit is trivial, receive is the hard part because you have to do CDR)
<solrize>
dk what cdr is but yeah receive is more complicated
<muurkha>
clock and data recovery
<muurkha>
their minimal four-instruction version just samples each bit once, at the point that it thinks is the middle of the bit based on the start-bit edge
<solrize>
looks like 9 instructions starting at line 50 but ok
<muurkha>
then they have a 10-instruction version designed to handle BREAK and framing errors
<solrize>
i guess that is what you usually do
<solrize>
stuff like parity can be done in the main cpu
<solrize>
with a lookup
<muurkha>
oh, I guess you're right that it's only 9
<muurkha>
yeah but ideally you'd like to, like, pay attention to the timing of the transitions, so that a little noise on the leading edge of the start bit doesn't result in bit errors throughout the whole byte
<solrize>
are there risc v cores with determinitic timing like the beaglebone pru? so no processor pipeline i guess
<solrize>
hmm ic
<muurkha>
and maybe sample more than once to figure out whether a bit interval is mostly 1 or mostly 0
<solrize>
yeah
<solrize>
or as a more extreme example, maybe a convolutional code based on adc readings
<muurkha>
yeah
<muurkha>
pipelines can be deterministic, usually are
<muurkha>
caches are the problematic part
<solrize>
hm ok. yeah bb pru has no cache, dk about pipeline
<solrize>
for a spread spectrum receiver you want an autocorrelator maybe a bunch of pios in parallel could do that
<muurkha>
interesting, I didn't know spread-spectrum receivers used autocorrelation. you mean to take advantage of multipath?
<solrize>
just to synchronize with the bit stream
<solrize>
multipath hmm i hadn't thought of that
prabhakarlad has quit [Ping timeout: 244 seconds]
<muurkha>
how does autocorrelation help you synchronize with a spread-spectrum bit stream?
<muurkha>
do you mean, like, to correct for doppler from a source moving at an unknown velocity, or to correct for clock speed error, or something?
<muurkha>
in this CDR notebook I used lots of convolutions but no autocorrelation (because I assumed the receiver knew the bit rate perfectly, just not the phase, and also there was an extra 10dB of noise which the receiver was able to handle because it sampled each bit 104 times)
loki_val has joined #riscv
crabbedhaloablut has quit [Ping timeout: 258 seconds]
<solrize>
muurkha, autocorrelation because of tiny differences in rate and offset between tx and rx clocks
<muurkha>
I'd think that the whole idea of the spreading code is to make the autocorrelation function of the original raw signal extremely small at all offsets other than 0, like an LFSR or Gold code
<muurkha>
but I don't really understand spread spectrum at all
<solrize>
let's say i have a bit stream to send at 1 mhz. so i xor it with a 10 mhz pseudorandom sequence. to recover the signal you xor the received stream with the same pseudorandom sequence. basically i start sending bits at 10 mhz starting at 0000 utc. a few hours later you want to start listening, so you use your clock to start your prng going at the right place. but if our clocks are a microsecond apart or one of them is 0.001ppm fast, there can be a big o
<solrize>
ffset and you have to search around (autocorrelated). that is an extreme example since there will usually be a short code (minutes) overlaid on the long code but you do need to search and adjust
<solrize>
you xor the pseudorandom sequence with the incoming signal at a lot of small shifts in parallel and see where you get a correlation. there is something else needed to adjust for speed differences but i guess the AC window is small enough that you can handle that separately
<solrize>
i have never implemented it, only read up on it a little
<solrize>
i've had the idea of using a pico as an infrared communicator
<solrize>
i guess using GPS as a time base could fix some sync probs
Gravis has joined #riscv
wingsorc__ has quit [Quit: Leaving]
epony has quit [Ping timeout: 252 seconds]
jacklsw has joined #riscv
epony has joined #riscv
wingsorc has joined #riscv
meowray has quit [Changing host]
meowray has joined #riscv
jacklsw has quit [Ping timeout: 240 seconds]
<pabs3>
muurkha: Longan are better than lychees :)
davidlt_ has quit [Remote host closed the connection]
davidlt_ has joined #riscv
davidlt__ has joined #riscv
davidlt_ has quit [Ping timeout: 252 seconds]
davidlt_ has joined #riscv
davidlt__ has quit [Ping timeout: 250 seconds]
Andre_H has joined #riscv
Andre_H has quit [Quit: Leaving.]
Andre_H has joined #riscv
mz___ has quit [Quit: Konversation terminated!]
<prabhakarlad>
conchuod: what is the status of your kconfig.socs cleanup? (I didnt see the patches in Palmer's tree).
<prabhakarlad>
I plan to send a v5 should I rebase on top of your patches?
<conchuod>
Nah, just sent it on top of for-next
<conchuod>
I sent a small bit of it as non RFC that I need to remind Greg about
epony has quit [Ping timeout: 252 seconds]
epony has joined #riscv
<prabhakarlad>
thanks.
awita has quit [Ping timeout: 250 seconds]
davidlt__ has joined #riscv
davidlt_ has quit [Ping timeout: 252 seconds]
davidlt_ has joined #riscv
davidlt__ has quit [Ping timeout: 272 seconds]
nvmd has joined #riscv
jobol has quit [Quit: Leaving]
qwer has joined #riscv
aerkiaga has joined #riscv
nmeum has quit [Remote host closed the connection]
nmeum has joined #riscv
Trifton_ has quit [Ping timeout: 272 seconds]
epony has quit [Ping timeout: 252 seconds]
epony has joined #riscv
Andre_H has quit [Quit: Leaving.]
awita has joined #riscv
<muurkha>
pabs3: longan and jackfruit are indeed amazing. I haven't tried rambutan
<muurkha>
solrize: you mean that if your signal after despreading has lots of ACF peaks it didn't have before, then you probably have the right timing?
Gravis_ has joined #riscv
Gravis has quit [Read error: Connection reset by peer]
zjason` is now known as zjason
Gravis has joined #riscv
<muurkha>
dh`: haven't had the pleasure of durian
Gravis_ has quit [Ping timeout: 272 seconds]
jacklsw has joined #riscv
jacklsw has quit [Changing host]
jacklsw has joined #riscv
Gravis has quit [Ping timeout: 264 seconds]
nvmd has quit [Quit: WeeChat 3.7.1]
rneese has quit []
vagrantc has joined #riscv
<dh`>
I have yet to get hold of fresh ones but I have run across some things like durian-filled cookies, and they're great
<dh`>
it's sort of weird because they do also have a foul smell attached, but that's not unprecedented either (e.g. stinky tofu)
jljusten has quit [Quit: WeeChat 3.6]
jljusten has joined #riscv
rneese has joined #riscv
foton has quit [Quit: %Bye, bye, ...%]
foton has joined #riscv
qwer has quit [Quit: Leaving]
qwer has joined #riscv
awita has quit [Quit: Leaving]
qwer has quit [Ping timeout: 272 seconds]
jljusten has quit [Quit: WeeChat 3.6]
foton has quit [Quit: %Bye, bye, ...%]
foton has joined #riscv
epony has quit [Remote host closed the connection]
aerkiaga has quit [Remote host closed the connection]
wingsorc has quit [Quit: Leaving]
jljusten has joined #riscv
rodrgz has joined #riscv
rodrgz has quit [Client Quit]
grgy has quit [Remote host closed the connection]
jacklsw has quit [Read error: Connection reset by peer]
nvmd has joined #riscv
grgy has joined #riscv
<rneese>
ok guys what boards are you all currently testing /using ?
<la_mettrie>
jh7100
<conchuod>
I've kinda got a bit of everything
<anotherNightmare>
qemu virt
<conchuod>
(or more accurately, most of what's linux capable)
<rneese>
la_mettrie what board
<rneese>
you usinf starfive or beaglev
<la_mettrie>
starfive
<rneese>
have you updated it for uefi support ?
<rneese>
I woul dlike to get your feeback on our imgs
<rneese>
also we are trying to get a unmatched board for dev to get support into the builder
<rneese>
we have jammy and sid imgs
<rneese>
but we need feed back on them
<rneese>
currently we have d1 and jh7100 beaglev / starfive support
prabhakarlad has quit [Quit: Client closed]
<conchuod>
who is "we"
<solrize>
muurkha, i don't know the lingo that well but i think that is the basic idea, the ACF peaks when the timing is right. maybe there is also a PLL to get the speeds sync'd
<la_mettrie>
rneese: no
<solrize>
rneese, i don't feel real excited by the idea of getting a low performance linux board just to be risc-v. i might get an esp32c3 or something like that
<rneese>
right now its still under dev abd our temo project name is RISCVbian . as it was based on armbian when we atarted it but the head of the project said he did not want riscv in the project so wer ported our branch
<solrize>
rneese, is this connected with rpi foundation?
<rneese>
no
<solrize>
k
<solrize>
is armbian connected with rpi and/or arm?
<rneese>
Armbian is Armhf/Arm64/
<rneese>
as it stands but we ported our branch and it is riscv only
<rneese>
we pulled all the arm stuff out for the most part and are working on it more to make shure
<mps>
rneese: we (alpine linux team) got 4 visionfive boards to 'port' alpine and test it. but I have feeling these boards are abandoned and I didn't worked much on it. just tested different peripherals on GPIO header