<_whitenotifier-f>
[scopehal] azonenberg closed issue #209: Rename TouchstoneParser class to reflect that it's really a generic S-parameter class - https://git.io/JJVEq
<_whitenotifier-f>
[scopehal] azonenberg closed issue #256: Issue to build the actual code with MSYS2 / MINGW64 related to TouchstoneParser.cpp code - https://git.io/JUEFA
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JUug6
<azonenberg>
So i just got off the phone with a sales guy at TRS-RenTelCo
<azonenberg>
The way their pricing works is that the base price is per month, per 2 weeks is 80% of that, and then per week is i think 60%
<azonenberg>
So basically for the most part it's not economical to rent one for less than a full month
<azonenberg>
I quoted three models in the same performance class as my current scopes: the Tek MSO54-BW2000, the R&S RTO2024, and the Keysight MSOS254A
<azonenberg>
R&S and Keysight were both in the $1.3K range and the Tek was significantly less at $800/mo
<azonenberg>
My tentative plan at this time is to finish initial feature-completeness of the lecroy driver in the next month or so, there's not really that much left to do on it
<azonenberg>
Hopefully you folks can improve Tek support a bit between now and then
<azonenberg>
Then in the late oct-early nov time frame i want to rent the Tek 5 series and spend a month building out a really solid scopehal driver for it
<azonenberg>
Which should go quick as LeCroy development is requiring i implement all of the API design and user interface stuff
<azonenberg>
adding new drivers is just driver code
<azonenberg>
also assembled MEAD boards eta monday
<miek>
have you tried asking the various social media reps for a loan?
<azonenberg>
I'm exploring various options. I have two different angles to pursue on Keysight - dan bogdanoff and NeroTHz
<azonenberg>
But $800 is cheap enough as test equipment goes that i'm probably just gonna do that
<azonenberg>
Not sure about R&S yet as I don't have any contacts there
<azonenberg>
NeroTHz's lab has millions of dollars of R&S VNAs but i don't think any of their scopes
<azonenberg>
I did just tweet-ping AlanAtTek to see what he can do
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #178: Figure out how to properly replay history from the start when adding new protocol analyzer filter, rather than only looking at the current waveform - https://git.io/JUudi
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #178: Figure out how to properly replay history from the start when adding new protocol analyzer filter, rather than only looking at the current waveform - https://git.io/JUudi
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #257: Allow specifying start and end times for filters and measurements - https://git.io/JUudS
<_whitenotifier-f>
[scopehal] azonenberg opened issue #257: Allow specifying start and end times for filters and measurements - https://git.io/JUudS
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #179: When placing a single cursor, highlight the relevant row in the protocol analyzer view if applicable - https://git.io/JUud9
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #179: When placing a single cursor, highlight the relevant row in the protocol analyzer view if applicable - https://git.io/JUud9
<_whitenotifier-f>
[scopehal] azonenberg opened issue #258: Digital buses should be packed binary, not a vector<bool>, to avoid excessive dynamic allocations - https://git.io/JUudb
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #258: Digital buses should be packed binary, not a vector<bool>, to avoid excessive dynamic allocations - https://git.io/JUudb
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #258: Digital buses should be packed binary, not a vector<bool>, to avoid excessive dynamic allocations - https://git.io/JUudb
<_whitenotifier-f>
[scopehal] azonenberg commented on issue #258: Digital buses should be packed binary, not a vector<bool>, to avoid excessive dynamic allocations - https://git.io/JUudj
<_whitenotifier-f>
[scopehal] azonenberg edited a comment on issue #258: Digital buses should be packed binary, not a vector<bool>, to avoid excessive dynamic allocations - https://git.io/JUudj
<_whitenotifier-f>
[scopehal] azonenberg opened issue #259: Eye pattern: allow phase offset in ps from reference clock to eye midpoint to be specified - https://git.io/JUuFK
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #259: Eye pattern: allow phase offset in ps from reference clock to eye midpoint to be specified - https://git.io/JUuFK
<NeroTHz>
azonenberg, I don´t know bout the cheaper R&S scopes, but we have an RTO1044 from R&S
juli965 has joined #scopehal
<NeroTHz>
Which is a 4 GHz scope I think. From Keysight, what I could find from a quick scan: MSO8104A (1GHz 4GSa/s), DSO-Z634A (63 GHz, 160 GSa/s) but this will likely be replaced with a UXR 70 GHz before the end of the year, DSA-X92004Q (20 GHz 80 GSa/s) which is essentially a DSAZ204A I think), MSO9104A and some others that were in use and I couldn´t look at. Also, from Tek, we have a DPO72004 (20GHz, 50 GSa/s)
<azonenberg>
That poor mso8104a
<azonenberg>
it probably feels so lonely and worthless surrounded by those million dollar scopes
<NeroTHz>
hehe
<NeroTHz>
We also have a good number of 1 GHz R&S scopes I thin
<azonenberg>
I just got somebody who says they've got a tek they can arrange remote access to
<azonenberg>
(6 series)
<azonenberg>
i still want to rent one to do hands on testing but that will probably be my next step re driver support
<NeroTHz>
oh I think there is also a Keysight MXR or a Tek 5 or 6 series on the way to the lab, but that is for the Low-frequency guys so I can´t really make any promises on that
<NeroTHz>
I would help talking to some of the local representatives but I don´t think talking to western-european sales people is gonna do you much good
<azonenberg>
"just a 6 GHz scope, for DC work"
<NeroTHz>
exactly!
<azonenberg>
signs you're talking to a mm-wave guy :p
<NeroTHz>
hehe ;p
bvernoux has joined #scopehal
<bvernoux>
hello
<azonenberg>
o/ bvernoux
<azonenberg>
did you try my fixes from last night yet for the windows build?
<bvernoux>
ha no let me try that now ;)
<bvernoux>
You could be interested by a things I'm working on ;)
<bvernoux>
it is a special chinese chipset doing amazing stuff for streaming ;)
<bvernoux>
example SATA, USB3.0 SS Device/HOST, with some lane with multi Gigabit ;)
<bvernoux>
and the fun is ALL is integrated
<bvernoux>
and it is ultra small in a convenient package
<bvernoux>
no BGA ;)
<bvernoux>
the most funny it provide a RISC-V MCU to configure the stream DMA ...
<bvernoux>
it has some SerDes also of course
<azonenberg>
NeroTHz: also i did some time domain sims last night
<azonenberg>
used the latest sonnet approximation of the probe to do channel emulation on some test waveforms
<azonenberg>
they looked quite nice and definitely had less overshoot than the v1.1 version
<bvernoux>
I have bought precision capacitor for RF ;)
<bvernoux>
will test them with my TRL and VNA
<bvernoux>
azonenberg, I'm cloning again the repo to rebuild all
<bvernoux>
[ 14%] Building CXX object lib/scopehal/CMakeFiles/scopehal.dir/SParameters.cpp.obj
<bvernoux>
C:\msys64\home\Ben\scopehal-apps\lib\scopehal\SParameters.cpp: In member function 'SParameterPoint SParameterVector::InterpolatePoint(float) const':
<bvernoux>
C:\msys64\home\Ben\scopehal-apps\lib\scopehal\SParameters.cpp:109:23: error: 'M_PI_4' was not declared in this scope; did you mean 'G_PI_4'?
<bvernoux>
let me force that manually to test it build
<_whitenotifier-f>
[scopehal] bvernoux commented on issue #256: Issue to build the actual code with MSYS2 / MINGW64 related to TouchstoneParser.cpp code - https://git.io/JUuNh
<bvernoux>
which was fixed by removing the M_PI macro replaced by pi
<_whitenotifier-f>
[scopehal] bvernoux edited issue #256: Issue to build the actual code with MSYS2 / MINGW64 related to TouchstoneParser.cpp / SParameters.cpp code - https://git.io/JUEFA
<azonenberg>
bvernoux: i included math.h, maybe not everywhere i needed it
<bvernoux>
strange the error is now on an other file
<bvernoux>
I suspect the build is not always in same order
<_whitenotifier-f>
[scopehal] bvernoux edited a comment on issue #256: Issue to build the actual code with MSYS2 / MINGW64 related to TouchstoneParser.cpp / SParameters.cpp code - https://git.io/JUuNh
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JUuA7
<_whitenotifier-f>
[scopehal] azonenberg b8266a2 - Added #include <math.h> in TouchstoneParser.cpp
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JUuA5
<azonenberg>
when i refactored the code into two files i added the include to one and not the other
<bvernoux>
let me clean all and clone again ;)
<bvernoux>
I have doubt with cache ...
<bvernoux>
same error again
<bvernoux>
with a fresh clone build
<bvernoux>
[ 14%] Building CXX object lib/scopehal/CMakeFiles/scopehal.dir/SParameters.cpp.obj
<bvernoux>
C:\msys64\home\Ben\scopehal-apps\lib\scopehal\SParameters.cpp:109:23: error: 'M_PI_4' was not declared in this scope; did you mean 'G_PI_4'?
<bvernoux>
C:\msys64\home\Ben\scopehal-apps\lib\scopehal\SParameters.cpp: In member function 'SParameterPoint SParameterVector::InterpolatePoint(float) const':
<bvernoux>
| ^~~~~~
<bvernoux>
| G_PI_4
<bvernoux>
C:\msys64\home\Ben\scopehal-apps\lib\scopehal\SParameters.cpp:121:18: error: 'M_PI' was not declared in this scope; did you mean 'G_PI'?
<bvernoux>
121 | phase_lo += 2*M_PI;
<bvernoux>
| ^~~~
<bvernoux>
| G_PI
<bvernoux>
C:\msys64\home\Ben\scopehal-apps\lib\scopehal\SParameters.cpp:123:18: error: 'M_PI' was not declared in this scope; did you mean 'G_PI'?
<bvernoux>
123 | phase_hi += 2*M_PI;
<bvernoux>
| ^~~~
<bvernoux>
| G_PI
<bvernoux>
C:\msys64\home\Ben\scopehal-apps\lib\scopehal\SParameters.cpp:129:22: error: 'M_PI' was not declared in this scope; did you mean 'G_PI'?
<bvernoux>
129 | if(ret.m_phase > 2*M_PI)
<bvernoux>
| ^~~~
<bvernoux>
| G_PI
<bvernoux>
C:\msys64\home\Ben\scopehal-apps\lib\scopehal\SParameters.cpp: In member function 'SParameterVector& SParameterVector::operator*=(const SParameterVector&)':
<bvernoux>
C:\msys64\home\Ben\scopehal-apps\lib\scopehal\SParameters.cpp:153:20: error: 'M_PI' was not declared in this scope; did you mean 'G_PI'?
<bvernoux>
153 | if(us.m_phase < -M_PI)
<bvernoux>
| ^~~~
<bvernoux>
| G_PI
<bvernoux>
C:\msys64\home\Ben\scopehal-apps\lib\scopehal\SParameters.cpp:155:19: error: 'M_PI' was not declared in this scope; did you mean 'G_PI'?
<bvernoux>
155 | if(us.m_phase > M_PI)
<bvernoux>
| ^~~~
<bvernoux>
| G_PI
<bvernoux>
C:\msys64\home\Ben\scopehal-apps\lib\scopehal\SParameters.cpp: In member function 'float SParameterVector::GetGroupDelay(size_t)':
<bvernoux>
C:\msys64\home\Ben\scopehal-apps\lib\scopehal\SParameters.cpp:177:52: error: 'M_PI' was not declared in this scope; did you mean 'G_PI'?
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JUuxP
<_whitenotifier-f>
[scopehal-apps] azonenberg 53f63d6 - Added _USE_MATH_DEFINES define on Windows
<azonenberg>
bvernoux: try latest and see if it solves the M_PI issue with no local modifications
<bvernoux>
ok
<bvernoux>
let me clean
<bvernoux>
i do a git clone ;)
<bvernoux>
yes it works
<azonenberg>
so does it build fully or are there other problems?
<_whitenotifier-f>
[scopehal] bvernoux commented on issue #256: Issue to build the actual code with MSYS2 / MINGW64 related to TouchstoneParser.cpp / SParameters.cpp code - https://git.io/JUuxQ
<bvernoux>
building
<bvernoux>
22%
<bvernoux>
it is very slow to build
<bvernoux>
I have removed -j as my PC is out of memory with 16GB RAM
<azonenberg>
you should still be able to do -j2 or something like that depending on how many other apps you have open
<bvernoux>
error
<bvernoux>
C:\msys64\home\Ben\scopehal-apps\lib\scopehal\LeCroyOscilloscope.cpp:2023:2: error: 'localtime_r' was not declared in this scope; did you mean 'localtime_s'?
<bvernoux>
2023 | localtime_r(&tnow, &now);
<bvernoux>
| ^~~~~~~~~~~
<azonenberg>
I would not recommend -j without a limit unless you have a lot of ram. On my workstation with 192GB i have no problem
<bvernoux>
I create a new issue for that error ?
<bvernoux>
it is localtime_r it is not standard
<bvernoux>
not recognized by mingw64
<sorear>
-j is such a terrible footgun
<bvernoux>
yes -j is open bar infinite thread ;)
<azonenberg>
sorear: yeah i think it should always require a limit
<bvernoux>
the fun is using that on a VM kill also the host on Windows7
<bvernoux>
what a crap ;)
<azonenberg>
If you have 192GB of RAM and 32 cores, you can get away with -j on most stuff
<azonenberg>
i can build full kicad from a new checkout in like 2 minutes
<bvernoux>
VirtualBox is crappy it does not respect the amount of ram allocated ;)
<bvernoux>
and it consume all possible ;)
<azonenberg>
bvernoux: what
<bvernoux>
azonenberg, I should have 3TB of RAM on my future computer If I have a promotion ;)
<azonenberg>
i knew virtualbox was bad but wow
<azonenberg>
i have a few vmware instances left over but am primarily xen now
<azonenberg>
both of those have been non-issues for me
<azonenberg>
bvernoux: file a separate ticket against scopehal for the localtime_r issue
<bvernoux>
also virtualbox have some sort of memory leak on long term it is awful
<azonenberg>
have to get back to $dayjob
<azonenberg>
i need to look at what the proper way to do that on windows is
<bvernoux>
let create an issue for the localtime_r ?
<sorear>
you start hitting hard tradeoffs between capacity and latency though
<azonenberg>
sorear: most C++ projects have a very wide, shallow dependency graph
<azonenberg>
compile everything then link
<azonenberg>
i saturate my cpus easily and have ram left over
<bvernoux>
-j option shall smarter anyway ;)
<bvernoux>
I consider it as a bug option ;)
<sorear>
azonenberg: yes
<sorear>
azonenberg: for very wide dep graph things I saturate all four DDR channels and ipc goes down to like 0.7 even though 64 threads are scheduled
<sorear>
and for narrow dep graph things I'm limited by memory latency
<azonenberg>
sorear: ah ok. I have six channels on each of two cpu sockets
<sorear>
either way the ram speed is the weak link of my current setup, I think if I removed half of it it'd reduce loading enough to increase the freq but I haven't tried
<azonenberg>
this machine was specifically configured to have max ram bandwidth, it has 8 dimm sockets (or pairs of sockets? i forget how many ranks) per socket but we only loaded 6
<azonenberg>
in order to balance things out better
<azonenberg>
empirically -j is fastere than without -j but i havent optimized to figure out the best count for my use cases yet
<azonenberg>
if i was bored and wanted to vtune i'm sure i could
<_whitenotifier-f>
[scopehal] bvernoux opened issue #260: Issue to build the actual code with MSYS2 / MINGW64 related to LeCroyOscilloscope.cpp - https://git.io/JUupw
<_whitenotifier-f>
[scopehal] bvernoux edited issue #260: Issue to build the actual code with MSYS2 / MINGW64 related to LeCroyOscilloscope.cpp - https://git.io/JUupw
<_whitenotifier-f>
[scopehal] bvernoux edited issue #260: Issue to build the actual code with MSYS2 / MINGW64 related to LeCroyOscilloscope.cpp - https://git.io/JUupw
<azonenberg>
Hmm, seems mingw doesnt like %zu either? (z = sizeof size_t)
<azonenberg>
i thought that was portable
<azonenberg>
Seems there may not be a universal way to printf an int64 or a size_t
<sorear>
the universal C99 way is to cast to intmax_t and use %ju
<sorear>
oh %zu is c99 as well
<sorear>
oh right because you're trying to use the msvcrt as though it were an ansi c libc
<azonenberg>
lol
<azonenberg>
I'm not familiar enough with mingw
<azonenberg>
i thought they actually used a windows glibc port
<azonenberg>
i guess that's not the case
azonenberg_work has quit [Ping timeout: 260 seconds]
<bvernoux>
azonenberg, for me universal way to print int64 is %lld
<bvernoux>
it was the most portable i found for Linux, Windows...
<azonenberg>
except int64_t on linux is afaik typedef'd as long not long long
<azonenberg>
so i get warnings in the opposite direction :p
<bvernoux>
ha bad ;)
<sorear>
you can cast it
<sorear>
and if your compiler is warning on casts that aren't even IDB your warning settings are wrong
<sorear>
mingw doesn't use glibc but it _is_ gcc so you could depend on gcc features if you wanted
<azonenberg>
I think that gcc will warn about casting a long long to a long even if they're the same size on the current platform
<azonenberg>
(at high warning levels)
<azonenberg>
because they may not *always* be the same size
<bvernoux>
I have not found other way to have a not too crappy code and fully portable on any platform
<bvernoux>
I think it is a good example to have a code the most portable which works everywhere ;)
<azonenberg>
I'll work on that after work
<azonenberg>
I want to do a more general warning cleanup rampage
<azonenberg>
I aim for 100% warning-clean code on linux but am not quite there, there's a handful i have to deal with
azonenberg_work has joined #scopehal
<bvernoux>
ha yes great
<bvernoux>
you can launch also CPPCheck for trivial bufferoverflow ... checks ;)
<bvernoux>
will try it
<bvernoux>
there is some nice recommendations towards C++ stuff with CPPCheck 2.1 too ;)
<azonenberg>
yeah i'm using 1.86 normally
<bvernoux>
2.1 is really better
<bvernoux>
even if it is far from more advanced static analyzer ;)
<azonenberg>
there are a few finds actually that i'll want to address
<bvernoux>
CPPCheck is very limited to parse complex code in fact
<azonenberg>
Longer term i want to integrate it into the build
<azonenberg>
if it's found, run it as an optional build step
<azonenberg>
via cmake
<bvernoux>
yes CI Build stuff
<bvernoux>
there is nice beta things available in github
<bvernoux>
called Code scanning alerts
<bvernoux>
which check code against vulnerabilities
<bvernoux>
I'm registered on the beta to check it
<bvernoux>
I was using ultra advancer static/dynamic analyzer in aero for that purpose
<bvernoux>
but they was crazy expensive like Polyspace
<bvernoux>
they was ultra advanced 10years ago I'm not sure it is so good now
<bvernoux>
I see they have released Polyspace Code Prover / Bug Finder now ;)
<bvernoux>
Coverity Scan can be useful too and is free for open source project
<bvernoux>
as scopehal/glscope is growing it could be interesting
<azonenberg>
Yeah. File a ticket against scopehal-apps for looking into static analysis
<bvernoux>
ok
<bvernoux>
especially you are using cmake which is good for that
<azonenberg>
Right now it looks like we have a total of about 68,000 lines, of which about 23K is scopehal, 25K is scopeprotocols, and the other 17K is glscopeclient
<azonenberg>
So not a small project but not a massive one either
<bvernoux>
I hate cmake but in fact it is good for multiplatform even if the syntax is so hard to remember ... ;)
<azonenberg>
(by comparison, kicad 5.1.4 is about 825K)
<bvernoux>
yes kicad is a monster ;)
<bvernoux>
your choice for libgtkmm-3.0-dev seems a very good choice at end
<azonenberg>
Also #37 (24c eeprom protocol decode/analysis) is on my list for tonight after i deal with your immediate portability issues
<bvernoux>
I see horizon EDA (a clone of KiCad with better stuff) is using it and it is really better than this poor wxWidgets which is full of traps everywhere
<azonenberg>
it's low hanging fruit that i've been meaning to do for ages
<bvernoux>
hehe
<azonenberg>
The other one i want to work on soonish is adding pcap export
<azonenberg>
ideally livestreaming pcaps to wireshark for usb/ethernet acquisitions
<bvernoux>
ha yes pcap export will be very nice
<bvernoux>
a must have for usb/ethernet stuff
<bvernoux>
I never have found such type of option on any scope ;)
<azonenberg>
I mean i already have lots of capabilities most scopes don't have
<bvernoux>
yes
<bvernoux>
it is why your project is more and more interesting ;)
<bvernoux>
I plan to buy a high end scope without any option just to use glscope ;)
<bvernoux>
To be free and not locked with those horrible and expensive UI provided with scopes
<bvernoux>
ok with recent high end scope the UI is very nice now ;)
<azonenberg>
The one thing options *are* good for is triggering
<bvernoux>
but SW option to decoder RS232/SPI are crazy expensive
<azonenberg>
there isnt any way we can do triggering in postprocessing
<azonenberg>
i'm actually thinking about buying the 8b10b option for my 4 GHz lecroy
<azonenberg>
not because i need an 8b10b decode but because that option also enables an 80-bit 3.125 Gbps serial data trigger
<azonenberg>
Which will allow me to trigger on things like a SGMII start-of-frame
<bvernoux>
you cannot add that feature in glscope ?
<azonenberg>
With my own custom hardware sure. But not with a third party scope
<azonenberg>
i need something that can run at full line rate and pattern match the incoming data with clock recovery
<azonenberg>
i mean i guess i could build my own external serial data trigger with an FPGA SERDES
<azonenberg>
But honestly at that point i might as well just build my own scope. Which is happening anyway
<azonenberg>
in general serial data triggers have to be done in hardware
<bvernoux>
ha ok it is a HW option in your lecroy scope
<bvernoux>
not only SW
<azonenberg>
I mean it's a software unlock for a feature that's already in the FPGA
<azonenberg>
But yeah
<azonenberg>
I suspect the i2c/spi/uart pattern triggers are also in fpga because of quirks of the implementations that i see
<azonenberg>
in particular it cannot mix analog and digital channels in a spi or i2c trigger
<bvernoux>
but yes trigger done in hw is a must have as in sw it is too late ;)
<bvernoux>
and not usable
<azonenberg>
you have to have data and clock be both analog or both digital
<bvernoux>
it is good for basic LA like salea which do all in SW side
<azonenberg>
yeah MAXWELL is going to have sophisticated FPGA based serial pattern trigger
<bvernoux>
each time you speak about MAXWELL I think about the equations behind ;)
<bvernoux>
I really do not understand why bunnie do that ...
<bvernoux>
so limited and will be so expensive for something with a soft core with 4h/5h battery life
<bvernoux>
especially all is done with ultra expensive tools
<bvernoux>
Altium for the schematic/board and Fusion360 or similar for the 3D stuff
<bvernoux>
very far from open source concept
<bvernoux>
and using Xilinx FPGA ...
<Degi>
Lol
<Degi>
Tbh xilinx series 7 should be fine soonish from an open source perspective
<bvernoux>
when Lattice is clearly better and more related to open source they have more open mind ;)
<bvernoux>
Xilinx XC7S50 !!
<bvernoux>
it is a brick ;)
<sorear>
it's been "fine soonish" since what, 2016/
<sorear>
>
<sorear>
?
<bvernoux>
compared to latest lattice FPGA
<bvernoux>
especially for a phone
<bvernoux>
and the Wifi Chipset is from Silicon Labs ;)
<Degi>
Hm, it has more logic than an ECP5 though
<Degi>
But less RAM than an equivalent ECP5
<bvernoux>
why it will be safe to use SL ;)
<Degi>
S?
<Degi>
SL?
<bvernoux>
Silicon Labs
<bvernoux>
as the aim is to have a phone fully check proof ;)
<bvernoux>
to avoid backdoor in CPU
<bvernoux>
the wifi chipset is clearly not check proof ;)
<bvernoux>
he did not mention anything on 2G/3G/4G chipset ;)
<bvernoux>
If he want to do that in the FPGA good luck with a poor XC7S50
<bvernoux>
it will be 2.5G with 10kbit/s
<bvernoux>
anyway it will match the perf of the soft core RISC-V @100MHz ;)
<bvernoux>
I do not imagine what we can do with that in 2020 it cannot even refresh a webpage
<bvernoux>
it can send email and to do voice call ;)
<bvernoux>
I really like bunnie for all things he do and the open source stuff idea behind but why such product ?
<bvernoux>
what the aim to sell 200units to 200geeks ?
<azonenberg>
I've thought about building a phone, but wasn't worth the effort. My plan was to use a COTS LTE modem module in a socket
<azonenberg>
want a new IMSI? swap the module :p
<azonenberg>
more importantly you can treat the modem as "the internet" and not have to trust it
<bvernoux>
yes buidling a phone is crazy but doing that with a FPGA + soft core ;)
<azonenberg>
it would be on its own power domain you could turn off with a hard switch
<bvernoux>
Imagine the heat
<azonenberg>
never see anything important
<bvernoux>
5h battery who want that ?
<smkz>
IMSI is from the SIM card
<smkz>
IMEI is the number burned into the modem
<azonenberg>
oh whoops mistyped
<azonenberg>
I meant IMEI
<bvernoux>
I just do not see the point
<azonenberg>
the idea (among others) was to decouple the modem from the phone-as-a-computer
<smkz>
but for certain modems it's possible to find procedures for ""repairing"" the IMEI
<bvernoux>
in such a limited device today
<Degi>
Hm maybe they can make a custom modem with a SDR
<smkz>
so you dont necessarily need to swap out the module to change the IMEI :)
<bvernoux>
Degi, it is proven to be a fail doing a SDR for 2G/3G/4G ;)
<azonenberg>
smkz: the other thing i wanted to do was support full e2e voice encryption over an ordinary GSM/LTE voice link
<Degi>
bvernoux, why is that?
<bvernoux>
Degi, you need a huge computer to have same perf as a poor 50USD phone in 3G/4G ;)
<bvernoux>
ASIC vs SDR cannot be compared
<bvernoux>
SDR is good for test ;)
<azonenberg>
the ideas was PCM -> codec2 -> AES-GCM -> FEC -> vocoder that converts binary data into something that will survive a lossy voice codec and still be readable
<Degi>
Well you can use a FPGA
<bvernoux>
Degi, FPGA vs ASIC is very far ;)
<bvernoux>
Degi, especially for a phone where you need low power ...
<bvernoux>
any SDR power consumption is HUGE ;)
<Degi>
The eagle / fusion thing is tbh reall yoof
<bvernoux>
maybe in 10 years with newer FPGA wo know ;)
<Degi>
That says YOU! *inserts piece of plutonium into phone*
<bvernoux>
yes ;)
<azonenberg>
Degi: no you're doing it all wrong
<azonenberg>
your phone doesn't need more than a little battery to handle brief periods of no cell coverage
<azonenberg>
you just need to make the tower TX power a lot higher
<Degi>
Apparently it has a secondary iCE40 too
<Degi>
Maybe we can fit a mini TWT amplifier inside
<bvernoux>
yes iCE40 to manage the battery and buzzer ;)
<azonenberg>
then have a bridge rectifier coming off the antenna into the battery charger
<azonenberg>
tesla wireless power :D
<azonenberg>
fcc RF exposure limits? what are those
<Degi>
Yes, actually convert your whole home with some shielding into a gigantic microwave
<bvernoux>
I just think the idea of FPGA Phone today is totally nonsense
<bvernoux>
with today battery, and today FPGA especially the poor XC7S50
<sorear>
at some point you need to ask questions about the power consumption of the transmitter
<bvernoux>
power consumption is crazy ;)
<sorear>
azonenberg: what if: cellular a la rfid
<Degi>
"200ppi black and white LCD (336x536 resolution), 100% inspectable with standard optical microscope" huh
<bvernoux>
yes idea is everything shall be inspectable ;)
<Degi>
"Approx. 100 hours standby with wifi+EC+static display enabled" hmm
<bvernoux>
I doubt about the 100h standby ;)
<Degi>
Also 1.1 Ah is kinda low huh, 5-6 h runtime sounds pretty impressive
<bvernoux>
with all the leakage in FPGA... ;)
<bvernoux>
Degi, yes with RISC-V soft core @16MHz ;)
<Degi>
What is a Li-Ion Battery Gas Gauge?
<bvernoux>
with refresh screen at 1fps ;)
<bvernoux>
and the must => Supports legacy USB 2.0 full-speed PHY
<bvernoux>
USB 2.0 FS what a dream
<Degi>
Now do they put pressure sensors into batteries or is gas something else
<bvernoux>
with such cheat you can forgot to take any photo or transfer big files ;)
<sorear>
it'll be interesting when people start making 5nm fpgas
<Degi>
Actually taking photos itself shouldnt be too hard if it has DDR inputs heh
<sorear>
the leakage wall is going to force hard tradeoffs between little fast transistors and larger, potentially stacked, low-power transistors
<bvernoux>
Degi, yes but it is not a planned feature anyway ;)
<bvernoux>
as it cannot be inspected ;)
<sorear>
depending on how things go we could wind up with config ram being effectively free and the fpga/asic gap, for once, narrowing
<bvernoux>
i'm sure bunnie will do something working
<bvernoux>
it is just what to do with such limited stuff which will be very hot too ;)
<sorear>
if we ever get to a point where EUV is used for the entire stackup that will also change things because EUV masks are consumables (being subjected to 100s of W of basically-X-rays is not good for any material) and are less subject to NRE
<bvernoux>
I see my Zynq7020 KC908 I imagine that with the phone even if the XC7S50 is far from a Zynq7020 ...
<Degi>
NRE?
<bvernoux>
other interesting point is how it will do 3G/4G ;)
<bvernoux>
it will do not
<bvernoux>
or only the broken implementation
<bvernoux>
anyway there is nothing related to GSM stuff
<bvernoux>
so a phone without 2G/3G/4G ?
<bvernoux>
it is an iPod ;)
<sorear>
non-recurring engineering costs
<bvernoux>
the concept of modular phone was more interesting even if it was a total flop
<Degi>
Kinda reminds me of the MNT Reform and that it only has one or two PCIe lanes and the NVMe slots are basically moot
<bvernoux>
here it is worse for a phone
<bvernoux>
it has no any feature of a real phone
<bvernoux>
just WiFi ;)
<miek>
you use a phone as.. a phone?
<bvernoux>
no there is way to emulate retro CPU ;)
<bvernoux>
it can be reconfigured to emulate a wide range of retro-CPUs, from the 6502 to the Z-80 to something we’ve never even heard of
<bvernoux>
woo
<bvernoux>
;)
<bvernoux>
when I read that I was thinking it is a joke
<Degi>
Cool, now my phone runs at 0.1 IPC
<bvernoux>
yes the RISC-V soft core was too fast ;)
<Degi>
It can probably run 10 6502
<bvernoux>
with 50Kcells yes even 20 ;)
<Degi>
I'm pretty sure 1 cell = a few transistors
<Degi>
And it only needs like 3.5 k
<bvernoux>
anyway the feature are similar to MNT Reform vs a true PC
<bvernoux>
it contains the power of a RPI4 for the price of a Ryzen7 Portable PC ;)
<Degi>
lol
<Degi>
Hm, they could have used the CPU from the ROCKPro64 or so, at least that has 4 PCIe lanes...
<bvernoux>
it is exactly the spec of MNT Reform
<bvernoux>
quadCore A53
<bvernoux>
I imagine they sell that 1500USD they do not win lot of money as there is crazy things to do but at end you have a poor RPI4 ...
<Degi>
Hm, it only has 2 PCIe lanes, one per socket...
<bvernoux>
yes it match with the spec QuadCore A53 ;)
<bvernoux>
I really cannot understand why to do such open source stuff
<bvernoux>
which are not competitive against anything
<sorear>
quad A53 is rpi3
<sorear>
rpi4 is A72
<bvernoux>
I really like the fact it is open source with KiCad
<bvernoux>
...
<bvernoux>
yes RPI4 is better than MNT Reform ;)
<Degi>
Yes and I think the case is in solvespace, also the idea with the batteries is relatively neat, though having 2 in parallel would be nice, since that'd allow for live swapping
<bvernoux>
MNT Reform is RPI3-- as I imagine the performance of the GPU Vivante vs RPI3
<Degi>
Actually the ROCKPro64 has 2x A72 1.8 GHz and 4x A53 1.4 GHz
<bvernoux>
for 50USD ? ;)
<Degi>
Well 70-100 but it also has 4 GB RAM and 4x PCIe...
<bvernoux>
Pine64 is dead IIRC
<Degi>
Whys that?
<bvernoux>
I was thinking they was bankrupt
<bvernoux>
with such low margin on their boards
<electronic_eel>
there is the purism librem 5 phone, it also has a separate cell modem, so the cpu is completely under software control. it seems to have a much more realistic feature set than bunnies toy thing
<Degi>
I recently bought a RP64 2 months or so ago
<bvernoux>
electronic_eel, yes clearly
<bvernoux>
electronic_eel, you agree that bunni phone is not a phone ?
<bvernoux>
maybe someone shall tell him ;)
<sorear>
is the ipod touch a phone?
<electronic_eel>
no, not a phone. just some geek toy, useless in everyday use
<bvernoux>
electronic_eel, haha yes
<bvernoux>
totally useless
<bvernoux>
I'm sure Bunni could do amazing project why does he loose his time on that
<bvernoux>
he could help to do very nice oscilloscope ;)
<electronic_eel>
he doesn't want to compromise on the "fully inspectable" thing. this means the feature set shrinks to useless
<bvernoux>
yes the point to have something fully inspectable is totally crazy
<bvernoux>
I like the concept but with actual tehcnology it is not possible
<electronic_eel>
engineering is always a tradeoff, and sometimes you select the wrong priorities. even with some small compromises on inspectable he could have big improvements re features
<electronic_eel>
like using a common arm cpu, but one without blobs
<bvernoux>
yes exactly
<bvernoux>
there is some good alternative
<bvernoux>
or acceptable maybe ;)
<bvernoux>
he seems to be blind with such feature of "fully inspectable"
<bvernoux>
and I imagine the price of the phone 500USD
<bvernoux>
as it will be very limited in quantity
<bvernoux>
even more on a site like Crowd Supply
<bvernoux>
with ultra limited visibility
<electronic_eel>
maybe it isn't designed to be used as phone at all and it is more to be used as a secure password storage or something
<bvernoux>
I was prefering when he was hacking the XBOX ;)
<bvernoux>
it is clearly presented as a phone
<bvernoux>
even compared with an iPhone ;)
<bvernoux>
for some features ;)
<Degi>
Why compromise on phone thickness when you can have 100 Ah battery
<miek>
i don't think it's presented as a phone at all
<bvernoux>
Compare to iPhone X at 70.9 mm x 143.6 mm x 7.7 mm and 174 grams
<bvernoux>
the size is compared to an iPhone X ;)
<miek>
so?
<miek>
that's a good measure of a thing people have in their pocket
<bvernoux>
this pocket-sized device remains smaller and lighter than the average smartphone
<bvernoux>
why to compare it to a smarphone in that case ?
<bvernoux>
yes it is never wrote it is a phone
<bvernoux>
as it is not
<electronic_eel>
now if it is not a phone and not a toy, what should it be used for?
<bvernoux>
Precursor is a mobile, open source electronics platform
<bvernoux>
so it is a thing ;)
<bvernoux>
but it is wrote
<bvernoux>
Precursor is a framework upon which you can assemble a wide variety of DIY mobile applications.
<electronic_eel>
hmm, that is too vague for me. he should at least have one good usage example
<bvernoux>
yes like book reader ;)
<bvernoux>
the 1st fully inspectable and open book reader ;)
<bvernoux>
you can read during 4/5h maximum ;)
<bvernoux>
oups
<bvernoux>
could have been fun if it will be a nice embedded hacking tool
<electronic_eel>
for a embedded hacking tool it has too few ios
<bvernoux>
yes ;)
<electronic_eel>
I envision something like Glasgow, but with a battery, screen and keyboard
<bvernoux>
yes it will be more interesting
<electronic_eel>
maybe wifi to offload bitstream synthesis
<bvernoux>
but as the aim was to be fully inspectable you cannot do anything with it ;)
<electronic_eel>
I think it is the wrong way round. why fix "fully inspectable" as a feature first, when you don't have a usecase in mind that really depends on this feature
<bvernoux>
yes exactly
<bvernoux>
the use case in mind was clearly a smartphone I think
<bvernoux>
but as it is the 1st version like a POC ...
<bvernoux>
but maybe because of that there will be never a full version to do a real phone
<electronic_eel>
if the smartphone really was the use case in mind it is an utter failure
<bvernoux>
miek, yes the principle of betrusted is nice but very far
<bvernoux>
we call that an "utopie" in french ;)
<bvernoux>
Utopia in english ;)
<bvernoux>
with actual technologie it is clearly an Utopia
<bvernoux>
hmm it seems github does not provide all the plugins there was before for static code analysis
<bvernoux>
since Microsoft has bought it
<bvernoux>
like Code Sonar or other they was free for open source ...
<bvernoux>
it seems they are not available now from github
<bvernoux>
Microsoft is removing all guys doing that maybe ;)
<bvernoux>
to push their own solutions
<bvernoux>
like they do for everything on windows10 with the integrated spyware and all the cheat like cortana ...
<bvernoux>
what a mess
<bvernoux>
and their awfull office360
<electronic_eel>
hmm, just read some of the betrusted documents and rationale. It is designed as a security tool, but I'm completely missing a threat model and some conclusions based on that. so I want the question "what is this thing designed to protect against, and what is it not designed to protect agains" answered first, based on that you can discuss feature sets and implementations
<bvernoux>
I replaced that cheat with LibreOffice at work as Office is more and more awfull and slow like hell
<bvernoux>
electronic_eel, it protect against nothing as it do nothing except WiFi ...
<bvernoux>
of USB FS ;)
<bvernoux>
maybe to protect you computer when you plug it ? :)
<bvernoux>
it is a usb key maybe ;)
<bvernoux>
and who know if someone will do not flash an evil bitstream ;)
<bvernoux>
what will protect against that ?
<bvernoux>
it is an endless loop ...
<bvernoux>
I do not understand the "Anti-tamper features"
<bvernoux>
when just after there is Made for developers
<bvernoux>
Easy-access developer's cable
<bvernoux>
Low-level debugging (GDB + Chipscope) and firmware flashing via developer's cable plugged
<bvernoux>
so you have some protections against evil guys but you can easily reflash and debug it ;)
<bvernoux>
ha ok it is Alpha phase to test things on FPGA
<bvernoux>
the AIM is to build SOC at end
<bvernoux>
it is just a very strange dev platform
<bvernoux>
without anything interesting/exciting to build a real product out of that
<bvernoux>
except checking some mechanism on a limited FPGA ...
bvernoux has quit [Quit: Leaving]
<electronic_eel>
miek: I think the part of the threat model is waaay too thin. why do you need full inspectability against evil maid attacks? what about an evil maid planting a small camera that films you entering the password,....
<electronic_eel>
I think this is not proper design where you first discuss threat models and conclusions from that in depth, and then go to features from that, but "I want to build a fully inspectable hardware, let's see what use cases I can find for that"
<Degi>
Hmm
<Degi>
What if it had a camera detector and IR flares...
<miek>
*sigh* cheeky ebay seller. i paid £210 for a scope that turned up faulty, they've offered £50 off... should be more like £150 off >.>
<Degi>
Lol
<Bird|otherbox>
azonenberg: have you looked at the clang-analyzer lately?
<azonenberg>
Bird|otherbox: nope
<Bird|otherbox>
that might be worth a shot re: static analysis
<Bird|otherbox>
(also, working on those merge conflicts now that I have kdiff3 installed)
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #180: Look into static analysis options - https://git.io/JUzmv
<Bird|otherbox>
and hit a weirder snag -- trying to figure out how lib/ got to be an empty folder between switching to the gui-dev branch and trying to merge in master
<Bird|otherbox>
I think I'll have to start over and do things the other way around :)
<Bird|otherbox>
because apparently gui-dev predates the submodule reorg?