Now that we monitor low level line status, we can fill in a proper
LOS signal along with the newly introduced AIS flag
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ied28b6b3da74f6a63a007fae889b571cc2c1e835
So that it's available without having to include the USB include ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I0b434cef7a662c19e5f48072285c013e8c02e254
The 'tick' system was meant to allow the firmware to monitor the
low level state of the line, beyong just "not aligned", but it was
never really useful in the present state.
Now we have more tick source available (but only one can be measured
at the same time). More specifically, the firmware can monitor the
presence/absence of raw pulses (LOS condition), it can also monitor
the number of '1' pulses to detect an AIS signals, or simply the rate
of RX pulses (to tune the local oscillator to incoming signal rate).
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I31fa8a717a26643f1b6ca5644bee1d8c41a2512e
This pulls in the support for non-crc4 framing modes and
also setting the Sa bits (for osmo-v5)
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ica1bbaa052988f5b7e71c7fa51f87eb0bfea6f67
There is really no need here, we can use `memcpy` just as well.
Not sure if this was a problem here but newer gcc are annoying
with aliasing rules and such so better safe than sorry.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I110ee4c014e8cfe058f7fc357decb7ab99e0be64
Mostly to get firmware code fixes
Need some code adaptation in icE1usb firmware to
remove local usb_cdc_notif_serial_state struct
sine tt's included in no2usb cdc proto header now.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I13e186627077c57329e4a83da11acc01ca5dce35
If the code is built either :
* without -flto
* with -fno-strict-aliasing
* with that struct as 'static' (so it's not on the stack)
Then all works fine. But in the current situation (without the
patch), GCC seems to think there is some aliasing and just plain
removed the `notif.bits = 1` bit of code in that functions
(no warnings printed ...).
Putting the struct as 'static' is the least awful workaround.
I didn't bother reporting bug upstream, because I can't reproduce
on a small test case and I'm sure I'd just get yelled at and that
the compiler is right for some reason ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ie0a2ce337ce4a9c08c3d27acc4d922a3e5892840
Those files barely even qualify for a license anyway but for
consistency's sake ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I9585f7f01d2dc8393828aa264ae353e2a53a37dd
Bug introduced in da395cc922
but since we never had anyway to use manual mode before,
didn't get noticed ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I6e2b6cf5c7c0c9deaf429be000770316ec88b9d4
* Renumber schematic pages
* Update the info cards with new data and r1.1
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ie5f3aa59e97fe46be9c857cf91ac4ff4ef72384e
Run the different job types based on a new environment variable, as the
software has to be built with a different docker image. The related
osmo-ci patch adjusts the jenkins jobs accordingly.
Co-developed-by: Oliver Smith <osmith@sysmocom.de>
Related: osmo-ci I90fbe72c722e491f41b9607d1a6389964d7e43b4
Change-Id: I26e839de419c6eb86bf2a6250a1adf06b761d1fa
This fixes the following Linux kernel error message on the host:
usb 1-1: config 2 has 2 interfaces, different from the descriptor's value: 3
Change-Id: Ideb816169a1e995907901c018e7bd2f963c1a831
Initially it was a good choice to keep the LIU driver in the host
software (easier debugging/changes). However, we never really needed it
to do anything but initialization of the LIU.
So in order to avoid having to teach osmo-e1d or other software the
details about the LIU initialization, let's do this from the firmware
*if* the e1d compatible USB configuration is used.
Closes: OS#5733
Change-Id: Id2217ff4573c4eebd816318128f256e85fb3c3bd
This adds a second USB configuration to the e1-tracer firmware. This
configuration is closer to the USB configuration of an icE1usb and hence
paves the way for using osmo-e1d with the tracer.
The main conceptual difference between the existing "legacy"
configuration and this new "e1d compatible" configuration is to have two
USB interfaces, one for each direction of the traced E1 interface. Each
interface has its own separate two altsettings, one for the disabled
and one for the enabled state.
Unmodified osmo-e1d will not work straight away with this, as it expects
ISO OUT and ISU Feedback endpoints, which a pure rx-only tracing device
of course doesn't have.
Related: OS#5733
Change-Id: I97062b9f12317b1b9b3855409c2380108cb921ff
Let's split the starting and stopping between the two channels.
This is a preparation for a future e1d-compatible mode where each
channel (direction) has its own USB interface and hence must be
individually started/stopped.
Related: OS#5733
Change-Id: I7492325352222269bf0ba1346511c7dfa99c4f64
Move icE1usb specific chapters to chapters/icE1usb/ to prepare for
the upcoming e1-tracer user manual.
Change-Id: I4c6cdd4036051469640b86860ea19736aa04364a
Let's explicitly specify the VID/PID of the e1-tracer in the dfu-util
invocation 'make dfuprog' to avoid accidentially programming other
attached dfu capable devices.
Change-Id: I6a17f01a621cd4af6827167427fafd2f9f277755
* make sure all projects and relevant links are mentioned
* indicate which sub-directories relate to which project
* use markdown syntax
Change-Id: If126790c5652a6228e8a8ad1986e3b08adf46fae
This was originally in https://github.com/smunaut/ice40-playground
but has meanwhile been removed, only a fork at
https://github.com/laf0rge/ice40-playground remained.
Let's import the code here. The history is not all that exciting
so I'm saving myself the effort of git filter-branch or the like
to import the actual old commits.
The commit log is here for reference:
commit bd36d40cc30acbae68978df79eff03f0539a9a21
Author: Harald Welte <laforge@osmocom.org>
Date: Fri Sep 4 10:21:51 2020 +0200
e1-recorder main.c: Don't exist just because one ISO transfer failed
I get LIBUSB_TRANSFER_ERROR every so often (once every few hours) on my
laptop. Sure, it likely means there was some data lost, but the trace
can continue juts fine after this error. So make it non-fatal and
continue running.
commit 9b02b3e87400ba3d27bff05e2632fbd5a0698e8c
Author: Harald Welte <laforge@osmocom.org>
Date: Mon Aug 31 10:01:20 2020 +0200
Add 'replay' to re-play 2Mbps stream with realistic speed (to stdout)
commit 23103d3a8f9cc8b3f0ba602dbb4240040b2d008a
Author: Harald Welte <laforge@osmocom.org>
Date: Sun Aug 30 15:41:12 2020 +0200
dump: Use osmo_e1f to decode; send HLDC over GSMTAP
commit 7acd063a1245a34835d4488be3caad592f3c19d5
Author: Harald Welte <laforge@osmocom.org>
Date: Thu Aug 20 16:48:15 2020 +0200
dump.c: Add error plotting support
commit 90b90d04fff494b70ad220bd82ac48d43f3096c9
Author: Harald Welte <laforge@osmocom.org>
Date: Mon Jan 13 18:20:39 2020 +0100
dump: Add support for writing LAPD PCAP of E1 superchannel
commit f3a0cc34f0901c2cf257367351dddfddc6f7301e
Author: Harald Welte <laforge@osmocom.org>
Date: Mon Jan 13 16:37:23 2020 +0100
dump.c: Move handling of frames to separate function
commit 8deffb5907979e43e3a4236ea7bb8d54513513ac
Author: Harald Welte <laforge@osmocom.org>
Date: Mon Jan 13 16:34:39 2020 +0100
dump.c: remove local hexdump.[ch] and use libosmocore proper
commit 80d81e78737237ba3b6bae1deb7d5107d7f613b6
Author: Harald Welte <laforge@osmocom.org>
Date: Tue Sep 1 13:52:52 2020 +0200
tracer: use 0x6151 as PID
See 5e68831b26
commit b219af27b34bbd6deb2419aa38852d8d227b9fc0
Author: Harald Welte <laforge@osmocom.org>
Date: Mon Jan 6 13:47:28 2020 +0100
e1-recorder: Don't silently ignore write failures
The disk may be full, for example. We should report that to the user
and terminate the program.
commit ead99fdfae6f1db54c79a91ef407a86c67352d87
Author: Harald Welte <laforge@osmocom.org>
Date: Mon Jan 6 12:41:23 2020 +0100
e1-recorder: Exit process on transfer + resubmit failure
This is particularly importnat in case the USB device for some reason
gets disconnected and re-connects. We want the process to fail fast
and have systemd respawn us.
commit a521e026c76056a60531c490fa2ef84e8e633c9a
Author: Harald Welte <laforge@osmocom.org>
Date: Mon Jan 6 12:35:20 2020 +0100
e1-recorder: use libusb_strerror() to decode error messages
commit 43a8fbdfdc35f5ba7564cfe5c92f43b124abf710
Author: Harald Welte <laforge@osmocom.org>
Date: Sun Jan 5 19:49:58 2020 +0100
e1-recorder: Acytually make '-r' (SCHED_RR) work
commit 84e28225d9ba1de9fb09660a96bd3b0b798c88d9
Author: Harald Welte <laforge@osmocom.org>
Date: Sun Jan 5 17:53:11 2020 +0100
e1-recorder: Add small 'dump' program
This program will print one line for each E1 frame, where each line
consists of 32 hex bytes: one for each timeslot
commit 0c697b40620b5d18480e626991dc639daadf58a6
Author: Sylvain Munaut <tnt@246tNt.com>
Date: Sun Dec 29 13:13:17 2019 +0100
projects/riscv_usb: Host software for the dual channel sniffer
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Closes: OS#5673
Change-Id: I9319c1eb8f822830307c1a181d357c58ce43efba
This is disabled by default because turns out the kernel doesn't
actually support PPS on CD for USB-CDC devices :(
And this also increase the interrupt traffic ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ie5d163434323a23912228003add9870fafefedf9
The original algo is just somehting I originally came up with
on the spot and worked and I never got the time to revisit.
Now after some testing, I implemented a PID loop that seems to
present faster lock time and at least as good stability.
Parameters were not thorougly optimized just some 'hand' tuning
trying to simulate the behavior.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ie3ea7243aa4234585f1ace222632bb5580caca75
Sylvain Munaut
Oliver Smith
Harald Welte