Custom calypso board
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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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
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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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:
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.
multi-master smells very much like CAN. Just saying.
On 11.07.2012 10:22, Alexander Huemer wrote:
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:
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.
multi-master smells very much like CAN. Just saying.
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.
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
Hi Cristian Paul, On Tue, Jul 10, 2012 at 08:57:43PM -0500, Cristian Paul Peñaranda Rojas wrote:
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?
Actually, both is true and there's little flexibility on that side :/
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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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
On Wed, Jul 11, 2012 at 07:55:45AM +0200, Mathias K. wrote:
* 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
My first thought for such kind of project was Compact PCI, but that maybe that blows the planned costs.
Hi Matthias, On Wed, Jul 11, 2012 at 07:55:45AM +0200, Mathias K. wrote:
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
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...
* 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
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.
* 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.
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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On 11.07.2012 10:26, Harald Welte wrote:
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
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.
* 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
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
Hi Mathias, On Wed, Jul 11, 2012 at 11:39:21AM +0200, Mathias K. wrote:
On 11.07.2012 10:26, Harald Welte wrote:
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 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.
There are some signs that the supply of Motola C1xx phones is not endless, after all.
And this include the cases as well.
no, not neccessarily. the cases are still being manufactured for spare part / re-work.
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 6-layer PCB will be espensive anyway, the milling of the connector is probably not a big impact, as you indicated.
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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On 11.07.2012 12:21, Harald Welte wrote:
On Wed, Jul 11, 2012 at 11:39:21AM +0200, Mathias K. wrote:
On 11.07.2012 10:26, Harald Welte wrote:
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 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.
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.
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?
Sounds good. Regards, Mathias
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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On 11.07.2012 14:51, Harald Welte wrote:
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).
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
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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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/plate... -- roh
Le 12/07/2012 01:06, Joachim Steiger a écrit :
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/plate...
--
roh
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
On 12.07.2012 03:29, Sébastien Lorquet wrote:
Le 12/07/2012 01:06, Joachim Steiger a écrit :
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?
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.
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
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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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
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:
http://www.micrel.com/page.do?page=product-info/multiplexers.jsp
The micrel parts are really impressive, but much too fast for our purpose (>2GHz). Chris
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
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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
participants (9)
-
Alexander Huemer -
Christian Vogel -
Cristian Paul Peñaranda Rojas -
Harald Welte -
Joachim Steiger -
Mathias K. -
Peter Stuge -
R M -
Sébastien Lorquet