Operation in GSM850 band requires IQ swap because of the offset PLL
used in the TRF causing spectrum reversal.
Thanks to Dieter Spaar for noticing the issue and the original patch
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
This way we can independentely control what frequency we want and
wheter we want to TX or RX. This allow TX on DL band and RX on UL band.
This also means all call to tx_window setup now need to properly set the
ARFCN_UPLINK flag !
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
This patch changes include paths to get osmocom-bb working with
the current libosmocore tree.
Among all these renames, you can notice several tweaks that I
added on purpose, and that require some explanation, they are:
* hexdump() in osmocon.c and osmoload.c has been renamed to avoid
clashing with hexdump() defined in libosmocore.
* gsmmap now depends on libosmogsm. Actually I had to cleanup
Makefile.am because I was experiencing weird linking problems,
probably due to a bug in the autotools. With the change included
in this patch, I got it compiled and linked here correctly.
This patch has been tested with the phone Motorola C123 and the
following images files:
* firmware/board/compal_e88/hello_world.compalram.bin
* firmware/board/compal_e88/layer1.compalram.bin
Using the osmocon, bcch_scan and mobile tools.
Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
It's up to L23 to change the parameters using the appropriate
L1CTL call.
This is a mix between Harald's version and Dieter's version of
the TX control code.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Instead of each primitive doing it independently, if there is a TPU
scenario in one of the item, we do a common setup with the base tn
returned by rfch_get_params.
Then each rx / tx window setup is relative to that 'base tn'. For
TX window, you have to explicitely request an offset of 3. (this
would allow for some test code to TX on ts=0 for eg.)
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Each item has a priority associated to it. The standard is :
-4 -> Responses processing
-3 -> L1S parameters changes
-2 -> [Reserved for TPU window setup]
-1 -> (anything)
0..7 -> Commands relative to time slot n
(relative to current l1s main timeslot)
8 -> (anything)
9 -> [Reserved for TPU window cleanup]
10 -> (anthing)
Note that with this modification, an item scheduled for the
current frame from within a call back won't have its priority
respected !
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
During IRQ handling, disabling and enabling IRQ may cause the same IRQ to
fire again. This is because the condition for this IRQ may be fullfilled
again, while still handling it. Using local_firq_save() and
local_irq_resore() intead, the IRQ handling will be completed before it is
cleared, and may then fire again.
The problem was detected during process of messages from layer23 to layer1.
In the IRQ context, the TX-functions of l23_api.c are called. There,
messages are queued and events are scheduled. During access to a queue or
a scheduler from any IRQ context or from normal context, interrupts must be
locked to prevent nested calls.
If it is not desired to call l23_api.c inside IRQ context, a message queue
must be used. If a message is written to that queue, it must be locked.
Afterwards a signal must be sent to the main process. The main process
locks the queue and de-queues the message. This is how it is done by all
layer 1 drivers of mISDN.
The interface between l1 and upper layer is called by several
name. IMHO l1ctl is shorted and sounds good so try to unify
using that.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
The new plan for layer1 is to structure the source code not based on
whether it is part of l1s/l1a or other parts, but based on 'primitives'.
All code that relates to transmitting a RACH burst should be in one
file, same for all code related to power management. Those files are
called layer1/prim_*.c
Max
Sylvain Munaut
Steve Markgraf
Harald Welte