<azonenberg>
tnt: this look right for starting to recover sync? i'm plotting cross correlation between the signal and the signal shifted by 3.2 ns
<azonenberg>
3.2 us*
<azonenberg>
Which is the duration of one 802.11n OFDM symbol minus the cyclic prefix
<NeroTHz>
my hack-way of doing carrier/phase sync is by just slowly rotating my constellation until EVM is minimized :p
<NeroTHz>
(please don´t do it that way)
<azonenberg>
Loool
<azonenberg>
Right now i'm doing a real valued plot of I only, not looking at complex components, but obviously to do real sync you'd want to do complex I+Q
<NeroTHz>
I was simulating dispersive channels, and it had this strange behaviour where the optimal amount of rotation was not the phase rotation at the carrier, but the phase rotation slightly above the carrier
<NeroTHz>
I guess because the amounto fdispersion above was flatter so it was more ´dominant´? I don´t know
<azonenberg>
This is a real measurement done in a somewhat unconventional manner
<azonenberg>
20mm nearfield H probe sitting right on top of the TX antenna for the DUT :p
<azonenberg>
(PCB trace wifi antenna)
<NeroTHz>
using a random WiFi tx that is just doing it´s thing/
<azonenberg>
Yep
<azonenberg>
Just so happens to be a gizmo i'm also doing testing on for $dayjob so it was on the lab bench anyway
<azonenberg>
No LNA or anything
<azonenberg>
the coupling is that strong
<azonenberg>
i'm getting +/- 300 mV into a 50 ohm scope input
<NeroTHz>
damn
<azonenberg>
So i'm not too worried about filtering out interference from, well, anything short of a nuclear EMP :p
<NeroTHz>
though a 20 dBm signal is not to be sniffed at, it´s what, 6Vp-p in 50 ohm environment?
<azonenberg>
i can't hear the laptop sitting a meter away on the same lab bench, or the AP about 2m above the bench on the ceiling
<miek>
you joke but that's probably next on the 2020 bingo card
<NeroTHz>
yeah you are just direct cfeeding into it
<azonenberg>
i mean i also have the scope trigger set to 100 mV lol
<azonenberg>
Which is one hell of a squelch
<NeroTHz>
I´m so used to bieng like ´Omg, -10 dBm output power from that transmitter? damn that´s crazy´
<azonenberg>
Lol
<azonenberg>
NeroTHz: I have about +6 dBm *at the RX antenna*
<azonenberg>
if my math is right
<NeroTHz>
that is a heck of a lot
<NeroTHz>
I suspect that measn you are well into the near-field of the transmitter antenna
<azonenberg>
meanwhiel the AP in the ceiling is seeing -36
<azonenberg>
NeroTHz: I'm using a 20mm nearfield H probe loop
<azonenberg>
it's meant for EMC testing
<azonenberg>
to find radiation from a PCB trace or something
<azonenberg>
but if you stick it at contact range on top of an antenna, it will couple. Quite strongly :p
<azonenberg>
NeroTHz: anyway, does that cross correlation look like a valid detection of the symbol sync?
<azonenberg>
the shape seems right
<azonenberg>
miek: i have no clue what's coming next but i bet it will be something nobody ever expected
<azonenberg>
Murder hornets weren't on my bingo card, that's for sure
<_whitenotifier-3>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±4] https://git.io/JJj0d
<azonenberg>
So now we have a peak right at the start of the waveform
<azonenberg>
Which makes sense that the packet would start on a symbol boundary
<azonenberg>
in this case our squelch is so perfect due to the extreme TX signal strength in the nearfield that i'm already perfectly synced :p
<tnt>
you should prett mych have a peak at every symbol.
<azonenberg>
Hmm
<azonenberg>
oh yeah my parameters are wrong
<azonenberg>
sec
<tnt>
How can this be negative ?!? you should be looking at the magnitude of the complex result.
<azonenberg>
this is a real value right now. I was just experimenting and didn't do the complex version
<azonenberg>
it's looking at I only
<azonenberg>
Guess i should do that
<tnt>
The outer sum shold also be limited in length to a few symbol time. Since you're not in perfect sync, it'll rotate a bit over time and so correlation will collapse.
<tnt>
Huh yeah, I'm not even sure this works in I only ...
<azonenberg>
I'm only doing a single symbol
<azonenberg>
But yeah let me make this complex
<tnt>
Let me check this CP thing works at all :p I have some LTE samples here I can quickly check this on.
<azonenberg>
Ok so what i'm doing now is, shift the waveform by "period"
<azonenberg>
then cross correlated "window" samples from the unshifted and shifted waveform
<tnt>
That's the kind of stuff I get when running this on my provider LTE cell. You see some periodic peaks, but sometime, they can be hard to discern from the noise depending on the symbol content ...
<azonenberg>
That's not even close to what i'm getting
<tnt>
Yeah, I never worked with wifi, so that might not work at all for such small FFT length ... (here I have FFT len=2048 ...)
<azonenberg>
lol
<tnt>
You can try asking in #gnuradio, folks in there have way more experience with signal processing and its theory.
<tnt>
(especially for this kind of "blind" approach when you don't want to rely on any of the specific standard caracteristics)
<tnt>
There is also something called Schmidl and Cox IIRC.
<tnt>
which is a pretty popular NDA way to find the symbols.
<tnt>
although it seems to still assume a preamble with a specific structure (which is probably why I never encountered it since I only do LTE and that doesn't have that)
<azonenberg>
tnt: that's with 1 and 2 symbol offsets
<azonenberg>
using schmidl & cox
<kbeckmann>
azonenberg: hi! i looked at the BLONDEL boards and they look really nice. just wanted to hear if you have been able to build any of the boards and verify some of the functionality yet?
<azonenberg>
there were a few small bugs but it worked after a couple of bodges, and is responding to SCPI commands over the UART to change gain/offset
<azonenberg>
not super exhaustively tested for linearity etc yet but works fine
<kbeckmann>
what kind of connector is that by the way?
<azonenberg>
As of right now, the PCB is netlist-complete but i have to go and add extra vias to a lot of power buses and do the final layout signoff review
<azonenberg>
which? the probe inputs?
<kbeckmann>
yes
<azonenberg>
SFF-8087, mini SAS
<kbeckmann>
ah interesting
<azonenberg>
meant to be 4 lanes of SAS TX/RX and some control lines, i'm using them as 8 lanes of unidirectional LVDS and then using the control lines for +12V power, presence detect, and UART management data
<kbeckmann>
8 lanes is quite a lot, nice.
<azonenberg>
oh, that's 8 lanes *per probe pod*
<kbeckmann>
right
<azonenberg>
Times twelve pods :D
<kbeckmann>
hehe yeah that is brutal.
<azonenberg>
There's a reason i have 40GbE to the outside world
<azonenberg>
a high-Z and differential version are planned but not short term priorities
<azonenberg>
This prototype is an oshpark board in a 3d printed box (oh, did i mention each channel has its own threshold, you're not locked to doing it per pod like in most LAs?)
<kbeckmann>
i see, but really nice to see the progress you are making here.
<kbeckmann>
that's cool
<azonenberg>
There is a CNC'd aluminum case, which is what i plan to use for the final units, at the factory now
<azonenberg>
just one prototype
<kbeckmann>
looking forward to see it!
<azonenberg>
as well as 25 boards at my PCB/PCBA shop in the process of being manufactured and assembled
<azonenberg>
they're doing the SMT only, i'm going to be putting on the LCD and final assembly with the enclosure in my lab
<azonenberg>
Assuming i like the CNC'd shell i'll make another 24 of them
<azonenberg>
25 pods is enough to outfit two complete MAXWELL systems plus have one spare
<azonenberg>
a German research group is sponsoring the project since they want to use the hardware with custom firmware for a research project, so I'm splitting the hardware cost with them and building one complete system for each of us
<kbeckmann>
oh that is awesome.
<azonenberg>
Anyway, so that has been my main priority on the hardware front, as well as continuing to iterate on the probe design and trying to make a higher bandwidth probe
<azonenberg>
The next step on MAXWELL is to finish the power routing and layout review, and i've just been too busy to touch it for the last week or two
<azonenberg>
it hasnt been a priority because it's going to be very expensive and i don't yet have the cash so finishing the pcb too soon isn't going to get it done any faster
<kbeckmann>
right, mistakes on these boards could become really expensive..
<azonenberg>
The bare PCB will be almost $2000 for a prototype batch
<azonenberg>
That's not counting the $1500 of parts , or assembly costs
<azonenberg>
Or the costs of machining the enclosure etc
<kbeckmann>
yeah i can imagine..
<azonenberg>
I expect the total up-front cost of building the two MAXWELL systems to be in the 6-7 kUSD range, plus the 4.2K for the probe pods, plus the probe pod enclosures. So it's a >$10K project all told
<azonenberg>
The university will of course be paying their share, but i can't send them the bill until i have a final price
<azonenberg>
Which won't be until fairly late in the process
<azonenberg>
anyway, there's still a ton of work to do on the FPGA side as well, i need to completely rewrite my TCP/IP stack to handle the bandwidth involved, design the trigger system, etc
<azonenberg>
MAXWELL will be my big focus in one way or another for probably 6-12 months once the boards are ordered
<kbeckmann>
alright. thanks so much for the details.
<azonenberg>
Anyway, so back to BLONDEL stuff
<azonenberg>
The next major step is to design the final analog board, which will consist of four copies of the AFE on that prototype board laid out on a single PCB, probably with a shield can over the top, and one ADC
<azonenberg>
as well as the FPGA board, which will consist of an XC7A100T/200T or XC7K70T/160T (exact chipset TBD based on price and final estimates of pin count), an INTEGRALSTICK module or just a bare STM32F777 for management, and a bunch of connectors
<azonenberg>
The FPGA board will be designed after the analog board, since its dimensions will depend on how big the analog board ends up being
<azonenberg>
although i guess schematic could happen first
<azonenberg>
And the analog board has one major missing piece that has yet to be prototyped
<azonenberg>
the AFE and ADC subsystems are pretty well characterized and tested at this point
<kbeckmann>
okay, what more is there? linearity, calibration?
<azonenberg>
The frontend is 50 ohm only, which means we need active probes to do high-Z inputs
<kbeckmann>
oh right
<azonenberg>
We need to design and prototype the active probe interface
<azonenberg>
Not the probe itself necessarily
<azonenberg>
but a means of supplying power and data to it
<azonenberg>
The current proposal is to use USB-C with a custom alternate mode, muxing +/- 7V DC onto the superspeed pins
<kbeckmann>
oh.. interesting
<azonenberg>
then using the usb 2.0 D+/D- pins for controlling the frontend on the active probe
<azonenberg>
This will allow the use of readily available USB cables for control, while also using commodity SMA cables for the RF side of the link
<azonenberg>
@einthecorgi2 indicated interest in working on this, then i never heard anything from him/her
<azonenberg>
And i've been too busy with MAXWELL to follow up
<kbeckmann>
ok but that sounds like a nice idea. what things are there left to figure out regarding this?
<azonenberg>
Prototyping the actual implementation
<kbeckmann>
mm i see
<azonenberg>
I want a known working schematic i can slap down on the analog board for BLONDEL and know that when we get around to doing an active probe, it will work
<kbeckmann>
i'm afraid this is way above my level
<azonenberg>
And i don't have the time to work on it myself
<kbeckmann>
so what would be needed here? on the scope side: +-7VDC supply, some bidirectional(?) communication protocol, MCU and some code that implements the protocol. and on the probe side, handle incoming voltages, another mcu that implements the protocol and can respond to commands?
<azonenberg>
Basically there needs to be a MCU on the scope side that implements a USB 1.x/2.x host port and possibly the usb PD protocol
<azonenberg>
as well as +5V and +/- 7V power rails
<kbeckmann>
oh so you intend to do actual USB
<azonenberg>
Yes
<kbeckmann>
i see
<kbeckmann>
is latency important?
<azonenberg>
i mean not more than ~100ms or so would be nice for UI responsiveness
<azonenberg>
but it's not super critical
<kbeckmann>
alright
<azonenberg>
anyway so it needs to establish communication with the probe, do some sort of handshake either via custom USB requests or USB PD requests (i.e. actual USB alt mode negotiation)
<azonenberg>
Once it's established it's talking to one of our probes and not any other USB device, turn on the +/- 7V power
<azonenberg>
as soon as the probe is removed, the +/- 7V rail has to be shut down so as to not kill an actual USB device which might be plugged in by mistake
<kbeckmann>
yeah that is a good point.
<azonenberg>
The probe needs to be capable of responding to USB traffic under +5V Vbus power only, the +/-7V rail only supplies the analog subsystem
<kbeckmann>
makes sense
<azonenberg>
you should be able to plug it into a PC and do a firmware update or query the ID info or something
<azonenberg>
although obviously it won't function as a probe in this state
<kbeckmann>
ok now it makes more sense. i like the idea!
<kbeckmann>
have you decided on which mcu family to use?
<azonenberg>
Also +/-7 is not a hard decision
<azonenberg>
the exact voltage might be TBD, and might even be variable per probe or something in the future
<azonenberg>
but it will be bipolar and somewhere between 5 and 12V for BLONDEL
<kbeckmann>
oh neat. the probe could request a certain voltage
<azonenberg>
That is the idea. USB PD is exactly what i want except it's a single rail
<azonenberg>
i need a negative rail
<azonenberg>
Hence the need to go custom
<kbeckmann>
makes sense
<azonenberg>
what i want to avoid is having SMPS's on the probe since that will add noise
<azonenberg>
And by having the MCU on Vbus rather than the analog rail we can keep that noise isolated
<kbeckmann>
oh right.
<azonenberg>
so Vbus stays 5V and has all the digital stuff, maybe use an LDO to 3.3V to power the digital side of an I2C/SPI DAC or something
<kbeckmann>
mm sounds nice
<azonenberg>
then analog power completely separate
<azonenberg>
anyway so the high level architecture is done, what needs to happen is somebody doing the legwork to actually implement it
<azonenberg>
on the host side what i want is a black box that i can give +/- N volts of analog power to, +5V Vbus, and let's say a SPI bus to the main MCU/FPGA
<azonenberg>
with a TBD protocol that allows me to send messages to the probe, query probe present/absent status, query the probe's requested voltage (for now always +/-7V but i want a command to make it variable in case we need that later on)
<azonenberg>
and probably read some usb descriptor metadata like probe model/serial number
<kbeckmann>
alright. yeah sounds like you have a nice design there.
<azonenberg>
the deliverable for me to be able to proceed with BLONDEL would be an assemble, working prototype host and device, including firmware, tested to function with each other and to not kill usb devices unaware of our protocol
<azonenberg>
assembled*
<kbeckmann>
nice. i am afraid i have too many side projects already etc. but now that i understand what you want to do, it doesn't sound too difficult.
<azonenberg>
So if you or anybody else in the channel wants to build that, go right ahead. Just talk to corgi first so you don't duplicate effort
<azonenberg>
i dont know how far they got
<azonenberg>
Yeah it's not hard
<azonenberg>
It's just a well defined, easily delegatable task
<azonenberg>
And i have enough on my plate as is
<kbeckmann>
yeah. and i think it could be reusable for other projects. having usb pd with a negative rail sure is useful for some.
<azonenberg>
I'm not working on it, nor do i intend to any time probably this year. If somebody wants to work on i will assist to the extent practical
<azonenberg>
and if a working implementation shows up in my lap it will be good motivation for me to get back to the final 4-channel BLONDEL analog board
<kbeckmann>
hehe nice. yeah i just don't want to promise/take on something too quickly. but i might check back later and perhaps help out.
<azonenberg>
But otherwise i will be working on glscopeclient and MAXWELL and the probes
<azonenberg>
Trying to fix the entire test equipment industry is more than i have time for :P
<kbeckmann>
yeah the test industry seems to have a lot of improvement areas..
<kbeckmann>
have a friend who works with custom factory testing equipment and oh the stories..
<kbeckmann>
factory => mass production / pcba testing
<kbeckmann>
seems there are so many things to improve and so little time, right?
<kbeckmann>
anyway, thanks for the chat! was nice to get a full picture of this.
<azonenberg>
tnt: anyway soooo
<azonenberg>
let's say i have this 802.11 signal which is OFDM with a FFT of 64 at 2.437 GHz
<azonenberg>
I mixed the original 10 Gsps with a 2.437 GHz LO in two phases and decimated by a factor of 100 to get two 100 Msps data streams
<azonenberg>
say i've identified the zero point in the signal for symbol sync
<azonenberg>
Now i need to do a 64 point FFT to recover each sample?
<azonenberg>
Do i need to resample the signal or something? because if i naively do a 64 point FFT on a 100 Msps complex stream i don't see how it will give me my symbols
<azonenberg>
So do i have to resample to the point that 64 samples are exactly one symbol long?
<azonenberg>
and if so, what is the point of the guard interval if the FFT includes it?
<azonenberg>
or do i do a 64 point FFT on one symbol not including GI, skip the GI, do another 64 point FFT on that?
<azonenberg>
on the next*
<tnt>
Yeah, you need to resample
<tnt>
You skip the GI, just drop it.
<azonenberg>
So i grab a single symbol, after aligning to symbol boundaries, at whatever my baseband sample rate is
<azonenberg>
resample to exactly 64 samples
<azonenberg>
then do a 64 point FFT to extract the symbol for each channel?
<tnt>
So resample you signal to 20 Msps. Then you drop 16 samples, take 64, FFT that. Then drop 16 samples, take 64 to FFT and so on and so forth.
<azonenberg>
Makes sense
<tnt>
The 64 samples after the FFT are your symbols. ( well you need to drop some of the unused bins, like the center one and the edge ones)
<azonenberg>
does this beast have a TCP/IP control interface?
<miek>
no :( only gpib
<azonenberg>
aww :(
<azonenberg>
I was gonna say, your hostname for it should be "Ernie"
<miek>
hah
<miek>
when i finally get around to making an ethernet -> gpib adapter, it shall be :p
<azonenberg>
We still need a scopehal gpib driver
<azonenberg>
If you want to write one
<miek>
afaik the gpib support landscape is a huge mess, so i'm making no promises yet ;)
<miek>
i do have an old hp scope on the shelf that i want to try with the agilent driver at some point, just for fun
<miek>
it'd be neat to say that the driver can support devices spanning >20 years
<miek>
yay. gauged everything and all in spec - they can leave quarantine now
<azonenberg>
Yay
<azonenberg>
I need to get some sma gauges
<azonenberg>
How much did you pay for yours again?
<miek>
... £80 :p
<azonenberg>
... lol
<azonenberg>
i'm not expecting to find a set THAT cheap
<miek>
the worst thing is they were up for £100 and i still made an offer. that was a bit of a dumb risk
<azonenberg>
lol
<azonenberg>
So right now i have the 6 GHz VNA, which works OK despite the software being a trainwreck
<azonenberg>
then the two power supplies, the two 5 3/4 digit DMMs, the 2 GHz scope, and the 4 GHz scope
<azonenberg>
Things on the wishlist now are a less awful VNA and higher bandwidth scopes (duh), but neither of those is a critical priority
<azonenberg>
then upgrading sonnet to silver/gold, a specan, and a proper signal generator. Possibly two, an RF vector siggen and a baseband AWG
<azonenberg>
then a SMA gauge set
<azonenberg>
I don't have budget for any of them but which do you think would be the most useful in the near term?
<azonenberg>
I feel like the specan is low on the list because i can just use fft mode on my scope for most stuff unless i need really high dynamic range
<miek>
realistically i think the sma gauges are low priority too. if you're careful, buying good stuff, and not using 3.5mm yet the risk seems very low
<azonenberg>
Yes that's been my thought too
<azonenberg>
Then siggens are *expensive*
<miek>
...yeah :(
<miek>
i've been looking out too, and even old second hand ones are still super pricey
<azonenberg>
So i'm seriously considering building my own, doing initial cal using my 4 GHz lecroy
<azonenberg>
then if i want better, sending it to a cal lab to get an official cal
<azonenberg>
I think that will be my next project post maxwell, in parallel with blondel
<azonenberg>
You saw the DAC i wanted to use right?
<miek>
although i want a fancy siggen, an sdr covers my needs pretty well
<miek>
mm, not sure
<azonenberg>
AD9154
<azonenberg>
quad channel 16 bit, 2.4 Gsps DAC rate, 1.096 Gsps data rate (built in interpolator)
<azonenberg>
8 lane JESD204B interface
<azonenberg>
my plan is a 1U system containing a kintex7, 1GbE, a stick of ddr3, a stm32f7, and one of these
<azonenberg>
to give you four lanes of ~500 MHz AWG
<miek>
noice
<azonenberg>
Then an external gain/offset stage
<azonenberg>
So you can select the full scale range and DC bias
<azonenberg>
The DAC is only $121 at digikey
<azonenberg>
So i think adding in the FPGA and PCB, a <$1K system is very doable in moderately low volume
<azonenberg>
Will probably be a six layer board using an xc7k70t in fbg484 but i have to do the math for speed grades and such to make sure that will work out
<azonenberg>
actually sorry it will have to be ffg676 to have enough transceivers
<miek>
shame about the eval board price, that'd be almost ready to go
<azonenberg>
which might mean the 160t as i dont think the 70 has that many serdes lanes
<azonenberg>
and well i want a whole packaged thing with front panel status display and everything
<azonenberg>
And OCXO timebase and 10 MHz refclk input, etc
<azonenberg>
and trigger in/out ports so you can sync a scope to the TX waveform
<azonenberg>
and of course a whole DDS platform on the fpga and library of standard waveforms etc
<azonenberg>
Anyway, i feel like that would be a nice project
<miek>
indeed
_whitelogger has quit [Ping timeout: 240 seconds]
_whitelogger_ has joined #scopehal
hlzr has quit [Ping timeout: 240 seconds]
<miek>
oh also my SMA threading die came in earlier, so i can get on with making the magic heatsink jig thing :)
<Degi>
threading die? Does that allow you to make SMA threads?
<miek>
yup
NeroTHz has quit [Read error: Connection reset by peer]