10 Jul
2012
10 Jul
'12
7 p.m.
Hi all!
There are some signs that the supply of Motola C1xx phones is not
endless, after all.
As such, sysmocom has decided to manufacture some custom boards with the
typical TI Calypso/Iota/Rita design. The RF PA will be RFMD RF3166, and
the combined NOR + SRAM will be a Samsung K5A3281. All parts are
still available from the surplus market.
Schematics will be published in PDF form only, Gerber/PCB files will not
be released (so basically the same like the OsmoSDR situation). All
software used is already available as OsmocomBB under a *GPL license.
Any help and input from the community will of course be appreciated.
The design will be more or less a standard tri-band calypso phone design
(900/1800/1900), with possibly a placement option for having
850/1800/1900. We'll be targetting a modem as opposed to a phone
design, so no built-in keypad / display / battery, but external
connections.
At one edge there should be a PCB edge connector, possibly with
mechanical form-factor of PCIe (sinc they're cheap). This connector
should allow the module to be plugged into a back-plane with a number of
other modems.
I've crated an initial Wiki page about the possible / intended
modifications from a classic phoned design at
http://bb.osmocom.org/trac/wiki/Custom_Calypso_Board :
* expose JTAG
* board-edge connector for plugging many boards into one backplane
* external clock input / buffered clock output
* RF connector standard u.fl or SMA or optionally separate Rx/Tx?
* I2C/SPI and both UARTs available on headers
* on-board EEPROM for storing persistent data, even beyond NOR flashing
* SIM card slot, SIM interface also present on header
* additional / unused TPU ports
* header for TSP / TPU and all data/control interfaces between iota/rita/calypso
* RTC crystal and footprint for lithium backup battery
* version of the board with uplink / downlink filters switched
Feel free to discuss other extensions/modifications you may have in
mind. Please note that fundamentally we are still heading for a calypso
based design, so this will not be a board that just contains the
Iota/Rita and some FPGA or general purpose DSP, as some people have
proposed in the past. However, it may be possible to have connector
footprints for the TSP / BSP interfaces and make some boarde that don't
contain the calypso/ram/nor parts.
Pricing will definitely not be anywhere near to the price of current
phones. You cannot even source all the components for the price of
those refurbished phones, let alone the fairly complex 6-layer PCB.
Also, the quantities will be low, we may be manufacturing something like
100 units a batch only.
This is a low-effort / side project, so I'm conservative with any
estimates and would say that we're happy to have boards shipping by the
end of this year.
Regards,
Harald (waiting for the e-mail flood)
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
11 Jul
11 Jul
12:11 a.m.
Harald Welte wrote:
I've crated an initial Wiki page about the
possible / intended
modifications from a classic phoned design at
http://bb.osmocom.org/trac/wiki/Custom_Calypso_Board :
* board-edge connector for plugging many boards into one backplane
..
Feel free to discuss other extensions/modifications
you may have in
mind.
How about USB to the backplane if 12Mbps is enough throughput? The
contacts are specified on the MiniPCI-E edge connector. Could also
try some trick with the SIM signals for when using real SIM.
//Peter
12:35 a.m.
Hi Peter,
On Wed, Jul 11, 2012 at 12:11:59AM +0200, Peter Stuge wrote:
How about USB to the backplane if 12Mbps is enough
throughput?
That might be an option, but it would require a cascade of USB hubs on
the backplane, and it would prevent the boards from talking to each
other in a peer-to-peer kind of fashion.
Also, as the Calypso itself doesnt' have USB, we'd need some kind of
external USB device controller hooked up to the calyposo UART / SPI or
even data/address bus.
Something like multi-master SPI would at leaset from a hardware point of
view support that.
Also, in addition to whatever bus we may choose, we should always have
some timing signals, so we can e.g. trigger events on board "B" by the
TPU on board "A".
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
10:22 a.m.
On Wed, Jul 11, 2012 at 12:35:17AM +0200, Harald Welte wrote:
On Wed, Jul 11, 2012 at 12:11:59AM +0200, Peter Stuge
wrote:
multi-master smells very much like CAN. Just saying.
How about USB to the backplane if 12Mbps is
enough throughput?
[...]
Something like multi-master SPI would at leaset from a hardware point of
view support that.
10:41 a.m.
On 11.07.2012 10:22, Alexander Huemer wrote:
On Wed, Jul 11, 2012 at 12:35:17AM +0200, Harald Welte
wrote:
CAN has a maximum theoretical data-rate of 1MBit/s. For the calypso cpu we need a external
CAN
interface and the CAN transceiver. If we really want to use CAN for backplane
communication i would
use, as example, a LPC11C24FBD48 with a integrated CAN transceiver as
"backplane" co-processor.
On Wed, Jul 11, 2012 at 12:11:59AM +0200, Peter
Stuge wrote:
multi-master smells very much like CAN. Just saying.
How about USB to the backplane if 12Mbps is
enough throughput?
[...]
Something like multi-master SPI would at leaset from a hardware point of
view support that.
3:57 a.m.
Schematics will be published in PDF form only,
Gerber/PCB files will not
be released (so basically the same like the OsmoSDR situation).
Is it due some restricted format from layout software or third party
contract clause?
As you mentioned there will not be LCM/Keypad or similar, useful for
a theoretically Open Hardware Phone, so by limiting access to
layout/gerber stops a bit the chance one some day can free it and make a
derivate work.
Hope not annoying with this question, but I would like to understand
better the situation, so may be we can learn from it to.
Cheers anyway for making this happen !
Cristian Paul
9:41 a.m.
Hi Cristian Paul,
On Tue, Jul 10, 2012 at 08:57:43PM -0500, Cristian Paul Peñaranda Rojas wrote:
Actually, both is true and there's little flexibility on that side :/
Schematics
will be published in PDF form only, Gerber/PCB files will not
be released (so basically the same like the OsmoSDR situation).
Is it due some restricted format from layout software or third party
contract clause? As you mentioned there will not be LCM/Keypad or
similar, useful for
a theoretically Open Hardware Phone, so by limiting access to
layout/gerber stops a bit the chance one some day can free it and make a
derivate work.
Well, I'd say there will be plenty of connectors. The LCD (even on the
compal/motorola phones) is just attached to I2C (plus the backlight
pwm). And the keypad is just the matrix.
We _may_ actually be able to put the circular "button" footprint for
something like the C123 keypad on the back side of the PCB, as so far
this is "only" a ground plane. Depends a bit on the effort, and
where/how somebody could source those thin membrane keyboards.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
7:55 a.m.
Hello,
just my comments:
Whats your planed form factor of the board?
Do you have choose the concrete calypso cpu already?
On 10.07.2012 19:00, Harald Welte wrote:
* expose JTAG
1.27mm 10 pol Pin-Header on the opposite side of the board edge connector, this make it
possible to
debug the board in a backplane
* board-edge connector for plugging many boards into
one backplane
I would suggest the ERNI SMC. There are also a cable assembly available.
http://www.erni.com/fileadmin/medien/downloadcenter/smc/ERNI-SMC-e.pdf
* I2C/SPI and both UARTs available on headers
* on-board EEPROM for storing persistent data, even beyond NOR flashing
There are different types available:
64KBIT: SOT23-5 - MICROCHIP - 24AA64T-I/OT
512KBIT: 8TSSOP - MICROCHIP - 24AA512-I/ST
...
It is a question of how much memory we need.
* SIM card slot, SIM interface also present on
header
* additional / unused TPU ports
* header for TSP / TPU and all data/control interfaces between iota/rita/calypso
* RTC crystal and footprint for lithium backup battery
* version of the board with uplink / downlink filters switched
Regards,
Mathias
10:25 a.m.
On Wed, Jul 11, 2012 at 07:55:45AM +0200, Mathias K. wrote:
My first thought for such kind of project was Compact PCI, but that
maybe that blows the planned costs.
* board-edge connector for plugging many boards
into one backplane
I would suggest the ERNI SMC. There are also a cable assembly available.
http://www.erni.com/fileadmin/medien/downloadcenter/smc/ERNI-SMC-e.pdf
10:26 a.m.
Hi Matthias,
On Wed, Jul 11, 2012 at 07:55:45AM +0200, Mathias K. wrote:
yes, good point. However, on that side there is likely the RF
transceiver and the antenna connections :( You probably don't want the
transmitter near the jtag cable...
undoubful great connectors, but I really wanted to keep it low cost,
thus the proposalf of using PCIe connectors on the backplane. Needs no
connector on the board itself, just a bit of board footprint.
thanks, I'm not quite clear on that myself yet. I just thought it makes
sense to be able to fully erase the NOR flash without impacting hard to
recover data such as calibration.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Whats your planed form factor of the board?
the core modem design is 40 x 29.8mm in size, but that of course
excludes things like the sim card reader, or any other new components we
may add.
After some first checking, that size would actually even fit nicely
within the mechanical form factor of the C1xx boards, as they have at
least something like 36 x 70 mm mechanical form-factor.
Now if thre was an _easy_ way to make one circuit board that would both
fit into the C1xx case _and_ also have a board edge connector for use in
a back-plane, I would consider doing that.
However, I think that's quite hard. The modem is likely smaller than
the phone PCB, and there would be a lot of constraints where to have
connectors for battery/sim/speaker/mic/vibrator, etc.
my first idea is to have a 'break away' backplane connector that one
would simply break off to mount it in a phone case. But then, if it is
intended to be broken (e.g. by perforating with a series of holes), the
PCB might break when it is plugged into the backplane and somebody
pushes it sidewise.
Do you have choose the concrete calypso cpu already?
Sure, the D751992AZHH. It seems to be widely available and known.
Contrary to the C1xx designs, it is not a "Calypso Lite", i.e. it has
512kByte internal SRAM and not just 256.
* expose JTAG
1.27mm 10 pol Pin-Header on the opposite side of the board edge
connector, this make it possible to debug the board in a backplane * board-edge
connector for plugging many boards into one backplane
I would suggest the ERNI SMC. There are also a cable assembly available.
http://www.erni.com/fileadmin/medien/downloadcenter/smc/ERNI-SMC-e.pdf * on-board
EEPROM for storing persistent data, even beyond NOR flashing
There are different
types available:
64KBIT: SOT23-5 - MICROCHIP - 24AA64T-I/OT
512KBIT: 8TSSOP - MICROCHIP - 24AA512-I/ST
It is a question of how much memory we need.
11:39 a.m.
On 11.07.2012 10:26, Harald Welte wrote:
yes, good point. However, on that side there is likely the RF
transceiver and the antenna connections :( You probably don't want the
transmitter near the jtag cable...
For development that's fine i think. But this is related to the planed backplane
connector.
undoubful great connectors, but I really wanted to keep it low cost,
thus the proposalf of using PCIe connectors on the backplane. Needs no
connector on the board itself, just a bit of board footprint.
Yes but that's only simple on one site and the board price increase because the extra
milling ways
but maybe for a 6 plane pcb it's not that much.
I think the initial hurdle to get it run on the table is really high with this kind of
connector.
How a developer or backplane board should looks like and whats the estimated price
relative to the
modem price?
Regards,
Mathias
the core modem design is 40 x 29.8mm in size, but that
of course
excludes things like the sim card reader, or any other new components we
may add.
So it looks like the MiniPCI Express Card on this picture
http://en.wikipedia.org/wiki/File:MiniPCI_and_MiniPCI_Express_cards.jpg ?
After some first checking, that size would actually
even fit nicely
within the mechanical form factor of the C1xx boards, as they have at
least something like 36 x 70 mm mechanical form-factor.
The question is, if you want to build a modem or re-engineer a phone for cases that:
There are some signs that the supply of Motola C1xx
phones is not
endless, after all.
And this include the cases as well.
Now if thre was an _easy_ way to make one circuit
board that would both
fit into the C1xx case _and_ also have a board edge connector for use in
a back-plane, I would consider doing that.
Make it simple.
my first idea is to have a 'break away'
backplane connector that one
would simply break off to mount it in a phone case. But then, if it is
intended to be broken (e.g. by perforating with a series of holes), the
PCB might break when it is plugged into the backplane and somebody
pushes it sidewise.
The 'break away' connectors came from manufacturing and they are not made to use
it on "harsh"
environments.
* expose JTAG
1.27mm 10 pol Pin-Header on the opposite side of the board edge
connector, this make it possible to debug the board in a backplane *
board-edge connector for plugging many boards into one backplane
I would suggest the ERNI SMC. There are also a cable assembly available.
http://www.erni.com/fileadmin/medien/downloadcenter/smc/ERNI-SMC-e.pdf
12:21 p.m.
Hi Mathias,
On Wed, Jul 11, 2012 at 11:39:21AM +0200, Mathias K. wrote:
no, not neccessarily. the cases are still being manufactured for spare
part / re-work.
I think the 6-layer PCB will be espensive anyway, the milling of the
connector is probably not a big impact, as you indicated.
On 11.07.2012 10:26, Harald Welte wrote:
I was thinking of a full-size PCIe connector like in desktop PC use.
This allows the modems to be 90degree angle from the main board. The
miniPCIe or miniPCI connectors require the modem to be flat on top of
the base board, reducing the density and increasing PCB size of that
backplane.
the core modem design is 40 x 29.8mm in size, but
that of course
excludes things like the sim card reader, or any other new components we
may add.
So it looks like the MiniPCI Express Card on this picture
http://en.wikipedia.org/wiki/File:MiniPCI_and_MiniPCI_Express_cards.jpg
? There are some
signs that the supply of Motola C1xx phones is not
endless, after all.
And this include the cases as well. undoubful great
connectors, but I really wanted to keep it low cost,
thus the proposalf of using PCIe connectors on the backplane. Needs no
connector on the board itself, just a bit of board footprint.
Yes but that's only simple on one site and the board price increase
because the extra milling ways but maybe for a 6 plane pcb it's not
that much. I think the initial hurdle to get it run on the table
is really high
with this kind of connector.
Well, we can always make a simple PCIe break-out board that you can plug
the modem into. That break-out could then provide you with a 2.54mm
pitch standard header. Would that work?
How a developer or backplane board should looks like
and whats the
estimated price relative to the modem price?
There's no thought about that so far, first we want to get the modem
done...
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
1:38 p.m.
On 11.07.2012 12:21, Harald Welte wrote:
Sounds good.
Regards,
Mathias
On Wed, Jul 11, 2012 at 11:39:21AM +0200, Mathias K.
wrote:
Do you mean the x16 with full-size PCIe?
Size/Pins:
PCI Express ×1 - 25mm - 36 pins
PCI Express ×4 - 39mm - 64 pins
PCI Express ×8 - 56mm - 98 pins
PCI Express ×16 - 89mm - 164 pins
http://en.wikipedia.org/wiki/File:PCIExpress.jpg
Do you have done some pinout done? The x16 (full size) is a really huge as connector.
On 11.07.2012 10:26, Harald Welte wrote:
I was thinking of a full-size PCIe connector like in desktop PC use.
This allows the modems to be 90degree angle from the main board. The
miniPCIe or miniPCI connectors require the modem to be flat on top of
the base board, reducing the density and increasing PCB size of that
backplane. the core modem design is 40 x 29.8mm in size, but
that of course
excludes things like the sim card reader, or any other new components we
may add.
So it looks like the MiniPCI Express Card on this picture
http://en.wikipedia.org/wiki/File:MiniPCI_and_MiniPCI_Express_cards.jpg
? 
I think the
initial hurdle to get it run on the table is really high
with this kind of connector.
Well, we can always make a simple PCIe break-out board that you can plug
the modem into. That break-out could then provide you with a 2.54mm
pitch standard header. Would that work?
2:51 p.m.
Hi Mathias,
On Wed, Jul 11, 2012 at 01:38:29PM +0200, Mathias K. wrote:
Do you mean the x16 with full-size PCIe?
I was thinking of x1 or x4. I already have done some other board with
x1 PCIe, so the footprint is already present.
However, now that I think of it, PCIe requires PCB thickness to be
different (1.5mm) from what we are hading for (more like .8 or 1mm).
So I guess I'll scrap that idea.
Do you have done some pinout done?
no, not yet. Things will move slow, we're in early planning phase
now...
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
10 p.m.
On 11.07.2012 14:51, Harald Welte wrote:
On Wed, Jul 11, 2012 at 01:38:29PM +0200, Mathias K.
wrote:
Your plan to use a 1.00mm thickness instead of the default 1.55mm increase the price by
around 50%
on, as example, WEdirekt. Why you need this thickness? Most time this is really useless
and only
increase the board costs. You should also think about bending, bga and small thickness.
Regards,
Mathias
Do you mean the x16 with full-size PCIe?
I was thinking of x1 or x4. I already have done some other board with
x1 PCIe, so the footprint is already present.
However, now that I think of it, PCIe requires PCB thickness to be
different (1.5mm) from what we are hading for (more like .8 or 1mm).
12 Jul
12 Jul
1:03 a.m.
Hi Mathias,
On Wed, Jul 11, 2012 at 10:00:10PM +0200, Mathias K. wrote:
Your plan to use a 1.00mm thickness instead of the
default 1.55mm
increase the price by around 50% on, as example, WEdirekt. Why you
need this thickness? Most time this is really useless and only
increase the board costs. You should also think about bending, bga
and small thickness.
I want to use a known 6 layer PCB stacking of materials / thickness that
we know works with the Calypso/Iota/Rita. Particularly on the RF side,
I don't want to spend time re-calculating all the impedance matched /
controlled parts. That's the part that is hard to measure if we get it
wrong. So just do the safe thing and stay with the "known working"
case.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
1:06 a.m.
Harald Welte wrote:
[...]
However, now that I think of it, PCIe requires PCB
thickness to be
different (1.5mm) from what we are hading for (more like .8 or 1mm).
So I guess I'll scrap that idea.
what about making it 2 pcb?
one 'gsm module' with 'plated half holes'* and or board to board conn.
one 'carrier board' which then has the right thickness for the pcie-con.
that way the sandwhich is mechanical stable and the rf performance
shouldnt be tampered with and can even serve as additional shielding if
needed (e.g. make side opposite to the modem gnd flat).
this makes the modules as small as possible for integration into
different kinds of carriers or even a full phone.
what do you think?
[*]
http://www.multi-circuit-boards.eu/en/pcb-design-aid/design-parameters/plat…
--
roh
3:29 a.m.
Le 12/07/2012 01:06, Joachim Steiger a écrit :
Harald Welte wrote:
[...]
I was about to suggest the same thing.
A very small 6-layer board with minimal/critical functionnality (not
even the sim) and then let people integrate that into simpler PCBs.
The RF can get out of the "critical" board via an UFL socket.
In the past, wavecom (now sierra wireless) had this idea. They developed
a modem core on a small PCB, using bga on the backside instead of plated
half holes. The packaging was made with a metallic shielding box.
Sebastien
However, now that I think of it, PCIe requires
PCB thickness to be
different (1.5mm) from what we are hading for (more like .8 or 1mm).
So I guess I'll scrap that idea.
what about making it 2 pcb?
one 'gsm module' with 'plated half holes'* and or board to board conn.
one 'carrier board' which then has the right thickness for the pcie-con.
that way the sandwhich is mechanical stable and the rf performance
shouldnt be tampered with and can even serve as additional shielding if
needed (e.g. make side opposite to the modem gnd flat).
this makes the modules as small as possible for integration into
different kinds of carriers or even a full phone.
what do you think?
[*]
http://www.multi-circuit-boards.eu/en/pcb-design-aid/design-parameters/plat…
--
roh
11:08 p.m.
On 12.07.2012 03:29, Sébastien Lorquet wrote:
Le 12/07/2012 01:06, Joachim Steiger a écrit :
There are more other companies that go this way (look at bt or zigbee) and you can use
this tiny
boards with every cpu of your choice because the simple interface. I don't think this
happens with
this kind of special hardware. I really don't know if it make sense to use a separate
rf-board and a
main-board. Is there any chance to use this rf-board with another platform (fpga,dsp ...)
then this
would make sense and also decrease the price of this platform.
Regards,
Mathias
Harald Welte wrote:
[...]
I was about to suggest the same thing.
A very small 6-layer board with minimal/critical functionnality (not even the sim) and
then let
people integrate that into simpler PCBs.
The RF can get out of the "critical" board via an UFL socket.
In the past, wavecom (now sierra wireless) had this idea. They developed a modem core on
a small
PCB, using bga on the backside instead of plated half holes. The packaging was made with
a metallic
shielding box. However, now that I think of it, PCIe requires
PCB thickness to be
different (1.5mm) from what we are hading for (more like .8 or 1mm).
So I guess I'll scrap that idea.
what about making it 2 pcb?
one 'gsm module' with 'plated half holes'* and or board to board conn.
one 'carrier board' which then has the right thickness for the pcie-con.
that way the sandwhich is mechanical stable and the rf performance
shouldnt be tampered with and can even serve as additional shielding if
needed (e.g. make side opposite to the modem gnd flat).
this makes the modules as small as possible for integration into
different kinds of carriers or even a full phone.
what do you think?
13 Jul
13 Jul
7:28 p.m.
Hi roh,
On Thu, Jul 12, 2012 at 01:06:34AM +0200, Joachim Steiger wrote:
what about making it 2 pcb?
one 'gsm module' with 'plated half holes'* and or board to board conn.
one 'carrier board' which then has the right thickness for the pcie-con.
It increases the cost quite a bit, and you will end up wasting a lot of
PCB space on the carrier board. Sure, I can understand where you're
coming from, but I'm not so sure if I'm convinced that it's the way to
go...
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
15 Jul
15 Jul
11:51 p.m.
Hi again,
there have been some comments and feedback to my original posting,
but I was actually naively hoping for a bit more input.
Particularly the "modifications" parts lile:
* external clock input / buffered clock output
Any ideas how this should be implemented? Adding the buffered output is
relatively simple, and it can always be present whether it is used or
not.
More interesting is the clock source, where I would like to see a
switchable clock source between:
* regular inetrnal VCTCXO
* external clock input (U.FL)
The external input could be sourced from one of our OCXO boards for
higher stability. Or you can of course source the clock input of one
board using the buffered output of another.
Does anyone have a good idea how to implement the actual switch? I
think it would be best to have it software-switchable from a GPIO...
* RF connector standard u.fl or SMA or optionally
separate Rx/Tx?
Here also we have the question of how to choose between the options.
If nobody comes up with a better idea, I would probably simply have a
placement option along the lines of a capacitor that can be soldered
either in the direction of the antenna switch (for duplex) or into the
direction of separate u.fl sockets for rx and tx. In fact,t we can e.g.
route Rx always via the switch and do that procedure only for Tx.
* additional / unused TPU ports
One of my ideas here was to be able to issue a TPU event from one board
and use it to trigger something on another board. The question is how
exactly the second half would be implemented. We could connect it to an
interrupt input (like sim card detect which even is a FIQ on the ARM).
But would that really help? Unfortunately the TPU has no triggers for
external events (which would be 100% synchronous).
If you have inputs to any of these topics, or have some other ideas of
what could or should be done, feel free to discuss them here!
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
16 Jul
16 Jul
10:11 p.m.
Hello,
On 15.07.2012 23:51, Harald Welte wrote:
The external input could be sourced from one of our
OCXO boards for
higher stability. Or you can of course source the clock input of one
board using the buffered output of another.
Does anyone have a good idea how to implement the actual switch? I
think it would be best to have it software-switchable from a GPIO...
http://www.micrel.com/page.do?page=product-info/multiplexers.jsp
Regards,
Mathias
17 Jul
17 Jul
2:54 p.m.
Hi all,
On Sun, Jul 15, 2012 at 11:51:22PM +0200, Harald Welte wrote:
More interesting is the clock source, where I would
like to see a
switchable clock source between:
* regular inetrnal VCTCXO
* external clock input (U.FL)
on the compal phones, a stand-alone oscillator (with control input) is
used, so I think you'll want to copy that. There are tiny single gate
multiplexers (e.g. 74LVC1G157) where NXP specifies a propagation delay
of 13ns max (125°C temperature, 1.65V supply), so it should certainly
work at 26Mhz (RITA's input wouldn't need the full voltage swing
anyway).
Does anyone have a good idea how to implement the
actual switch? I
think it would be best to have it software-switchable from a GPIO...
Switching the clock will produce a glitch, but we should be able
to run the ARM core from the 32kHz clock crystal during that period,
I think (but will have to check) would we really want to toggle
between the two inputs? Do we want to autodetect a valid ext. refclock?
On Mon, Jul 16, 2012 at 10:11:50PM +0200, Mathias K. wrote:
The micrel parts are really impressive, but much too fast for our
purpose (>2GHz).
Chris
18 Aug
18 Aug
9:19 a.m.
Hi,
* expose JTAG
* board-edge connector for plugging many boards into one backplane
* external clock input / buffered clock output
* RF connector standard u.fl or SMA or optionally separate Rx/Tx?
* I2C/SPI and both UARTs available on headers
* on-board EEPROM for storing persistent data, even beyond NOR flashing
* SIM card slot, SIM interface also present on header
* additional / unused TPU ports
* header for TSP / TPU and all data/control interfaces between iota/rita/calypso
* RTC crystal and footprint for lithium backup battery
* version of the board with uplink / downlink filters switched
I would suggest the board to have a connector that sends the I Q
signals from say openbts directly to the dsp so that there wiil not be
a need a usrp or any other rf board/singal generator to send the
signal through the SMA connector.
I would also suggest that DSP code be modified and not placed in DSP
ROM. This would help in writing our own dsp code and make the software
totally opensource.
Regards,
RM
11:42 a.m.
Hi RM,
thansk for your feedback.
On Sat, Aug 18, 2012 at 12:49:34PM +0530, R M wrote:
I would suggest the board to have a connector that
sends the I Q
signals from say openbts directly to the dsp so that there wiil not be
a need a usrp or any other rf board/singal generator to send the
signal through the SMA connector.
I'm not quite sure if I'm following you. OpenBTS is software, which
runs on e.g. a PC. You want to get I/Q samples from the OpenBTS
transceiver program to the DSP. What kind of "connector" do you
suggest? The DSP doesn't have any interface that you could attach
directly to a PC.
Also, OpenBTS 'transceiver' itself implements more or less the same
functionality as the DSP in the Calypso. So why would you want to
interface the two? You want to run the Calypso board as a phone, and
OpenBTS as the GSM network and interface them directly using digital
baseband samples? Then you would have one phone attached to one BTS,
not a very exciting setup for testing :/
I would presume as opposed to your suggestion, it would make more sense
to interface the ABB chip with the OpenBTS transceiver, _bypassing_ the
DSP. This way, you could run the Calypso board as an inexpensive
transceiver, using its ABB + RF Frontend as a cheap radio.
I would also suggest that DSP code be modified and not
placed in DSP
ROM. This would help in writing our own dsp code and make the software
totally opensource.
lol. And how exactly do you suggest to achieve that? As the name
implies, it is _read only memory_. How should we change the contents of
a mask rom on a chip that was manufactured years ago in a TI fab? ;)
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
4700
days inactive
4739
days old
baseband-devel@lists.osmocom.org
24 comments
9 participants
participants (9)
-
Alexander Huemer -
Christian Vogel -
Cristian Paul Peñaranda Rojas -
Harald Welte -
Joachim Steiger -
Mathias K. -
Peter Stuge -
R M -
Sébastien Lorquet