All,
I have a Racal/Aeroflex 6113 for sale. As most of you probably know, this is
a GSM test set capable of initializing and running certain BTS over an ABIS
link. It has a few handy features such as a power meter, etc. The unit is
out of cal. I have used it to run measurements on an Ericsson RBS 2401,
which is also available. Comes with power cord and a memory card for storing
test sequences and test results. The unit is well loaded with options, as
seen below. To my knowledge all functions of this unit work. Asking price is
$1500 USD + shipping. I am willing to ship overseas, BUT, it is the buyers
responsibility to complete all import/export paperwork needed. Be advised it
is a rather heavy unit, so shipping OCONUS will be more expensive. Any
questions please feel free to contact me off list at cleb(a)defcon-3.net.
Options:
Software Options:
003 PCS1900
008 GSM850
220 Ericsson
235 Siemens
250 Nortel
270 Nokia
285 interWAVE
300 AIME
310 BOSS BTS Rx Measurements
315 AMR for AIME
316 AIME AMR DTX output
319 AMR AIME error forcing
Hardware Options:
04F Frequency Standard
A-bis Half Rate/32K Signalling
051 A-bis T1 Interface
054 BOSS RF Module
016 Extended BBP Board
008 GSM850/PCS1900 RXTX Module
010 Encryption A5/1, A5/2
Regards,
Caleb
hello,
I updated my openbsc to newest git version. and since then I do not get any sounds.
The setup was working just fine before. So I presume that the problem is within openbsc
<000b> osmo_msc.c:72 Assignment complete should not have been reached.
<000b> bsc_api.c:331 Sending ChanModify for speech 0 1
<000b> bsc_api.c:118 Using non speech mode: 0
I think this causes the problem. But I have not changed any configuration files or anything.
Can somebody tell me how to fix it?
I am using a 1900mhz edge nanobts
Hello -
I have been using Wireshark 1.7 from wireshark.org for GSMTAP analysis. I have seen some discrepancies that might be bugs. So I have two questions. First, is there a better-suited WS with more up-to-date GSMTAP support that I should be using (and hopefully pre-built for Mac OS X)? Second, where should I report these suspected bugs?
-- David
Hello,
I'm new around here and started from scratch with a new Ubuntu server. I
followed the openBSC build guide on the WIKI page
http://openbsc.osmocom.org/trac/wiki/Building_OpenBSC.
Building libosmocore went smoothly
Building libosmo-abis ended in an error:
=====
checking for ORTP... no
configure: error: Package requirements (ortp >= 0.13.1) were not met:
No package 'ortp' found
=====
Where can I find the ortp package?
And secondly, is this the right version? I saw version 0.15.0 mentioned in
the mail archives aready.
Thanks in advance,
Peter.
I am trying to generate CRC table mentioned in
openbsc/src/gprs/crc24.c file
(http://lingrok.org/source/xref/openbsc/openbsc/src/gprs/crc24.c)
I modified a CRC16 code to generate CRC24 (updated polynomial as per
LLC specification). But I can not get right table.
Below is source code. Can someone help me out?
//******************************************************************************
//
// Copyright (c) 1999 Axon Instruments.
// All rights reserved.
//
//******************************************************************************
// HEADER: CRC16.cpp
// PURPOSE: Contains functions calculating a 16 bit CRC code.
// SOURCE: http://www.brokersys.com/snippets/ file: CRC_16F.C
//
#define POLYNOMIAL 0xAD85DD
#define CRC_WIDTH 24
#define BITS_PER_BYTE 8
typedef unsigned int WORD;
typedef unsigned int UINT;
typedef char BYTE;
static WORD correctCRCtable[1<<BITS_PER_BYTE] = // as per
openbsc/src/gprs/crc24.c
{
0x00000000, 0x00d6a776, 0x00f64557, 0x0020e221, 0x00b78115,
0x00612663, 0x0041c442, 0x00976334,
0x00340991, 0x00e2aee7, 0x00c24cc6, 0x0014ebb0, 0x00838884,
0x00552ff2, 0x0075cdd3, 0x00a36aa5,
/* skip rest */
};
void InitCRCtab()
{
int v, i;
int b;
for ( b = 0; b <= (1<<BITS_PER_BYTE)-1; ++b )
{
int v = b << (CRC_WIDTH-BITS_PER_BYTE);
int i;
for (i = BITS_PER_BYTE; --i >= 0; )
v = v&0x800000 ? (v<<1) ^ POLYNOMIAL : v<<1;
if((v & 0xFFFFFF) == correctCRCtable[b])
correctCRCtable[b] = v;
else {
printf("Incorrect CRC table\n");
printf("correctCRCtable[%d]=0x%06x calculated=0x%06x\n", b,
correctCRCtable[b], v&0xFFFFFF);
exit(0);
}
}
}
int main()
{
InitCRCtab();
printf("Correct CRC table\n");
return 0;
}
/*
Below is LLC specification:
The FCS field shall consist of a 24 bit cyclic redundancy check (CRC)
code. The CRC-24 is used to detect bit errors in the frame header and
information fields.
The FCS field contains the value of a CRC calculation that is
performed over the entire contents of the header and information
field, except for UI frames transmitted in unprotected mode, in which
case the FCS field contains the value of a CRC calculation that is
performed over the frame header and the first N202 octets (see
subclause 8.9.6) of the information field only (see subclause
6.3.5.5.2). The information over which the CRC is calculated is
referred to as the dividend in this subclause. Bit (1, 1) of the
dividend is the highest-order term in the calculation (see subclause
5.7.3). CRC calculation shall be done before ciphering at the
transmitting side, and after deciphering at the receiving side.
NOTE: The definition below is different from that in 3GPP TS 24.022
[10] only with respect to the variable dividend length k of the LLC
frames. In 3GPP TS 24.022, the RLP frame has a fixed dividend length,
but the LLC frame has a variable dividend length.
The CRC shall be the ones complement of the sum (modulo 2) of:
- the remainder of x^k (x^23 + x^22 + x^21 +... + x^2 + x + 1) divided
(modulo 2) by the generator polynomial, where k is the number of bits
of the dividend; and
- the remainder of the division (modulo 2) by the generator polynomial
of the product of x^24 by the dividend.
The CRC-24 generator polynomial is:
G(x) = x^24 + x^23 + x^21 + x^20 + x^19 + x^17 + x^16 + x^15 + x^13 +
x^8 + x^7 + x^5 + x^4 + x^2 + 1
The result of the CRC calculation is placed within the FCS field as
described in subclause 5.7.3.
NOTE: As a typical implementation at the transmitter, the initial
content of the register of the device computing the remainder of the
division is pre-set to all "1's" and is then modified by division by
the generator polynomial (as described above) of the dividend; the
ones complement of the resulting remainder is put into the FCS field.
As a typical implementation at the receiver, the initial content of
the register of the device computing the remainder of the division is
pre-set to all "1's". The final remainder, after multiplication by x24
and then division (modulo 2) by the generator polynomial of the
received frame, will be (in the absence of errors):
C(x) = x^22 + x^21 + x^19 + x^18 + x^16 + x^15 + x^11 + x^8 + x^5 + x^4
*/
Hi all,
Dieter and I have been thinking about building a simple/basic E1 line
interface. The idea is to simply put trnasformers + LIU + crystal on a
small PCB, which then exposes the Rx and Tx signals at stanard 3.3V CMOS
levels which can be fed in your favourite FPGA or even directly into a
microcontroller.
The first interesting LIU that's available in single quantity is the
Dallas/Maxim DS21348:
http://www.maxim-ic.com/datasheet/index.mvp/id/2848
It can be operated in "software mode" where all configuration (E1/T1/J1,
attenuation, amplification, termination, ...) is set via SPI from a
microcontroller.
However, it expose "Rx Positive" and "Rx Negative" and does not have the
HDB3/AMI/B8ZS encoder internally. This means there would be two synchronous
serial streams going into the FPGA or microcontroller. This is probably
ok for an FPGA - but it is a problem for most microcontrollers that only
have one sync serial interface like the sam3s/sam7s SSC.
The other option seems to be the IDT 82V2081
(http://www.idt.com/?genId=82V2041E&cid=58553), which as internal
HDB3/AMI/B8ZS encoders and decoders (so-called "single rail mode"). It
is a bit more expensive (USD 20 in single qty), but this would enable us
to hook it up directly at a sam3s / sam7s.
As jolly points out, there is still a lot of work required like
framing, s-bits, multiplexing, hdlc, etc. in order to turn it into a
full E1 interface.
But then, maybe there are some applications that don't even require all
those features, such as building a sniffer-only device, or something
that "simply" tries to forward E1 over IP based transports without
parsing too much of the contents.
Open questions:
* stay with 1port design or immediately do a 4port unit? (for
bidirectional sniffing you already need two)
* how do we achieve synchronization between Rx and Tx data path?
Looking forward to your comments, feedback.
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)
Hello everyone,
I've just finnished writing together a small web interface for the
OpenBSC HLR. It allows you to modify various parameters in the
database and also provides a set of functions to modify the HLR or
sending SMSes in your own scripts.
The project is still very alpha but it seems to work reasonably good.
Feel free to give any feedback!
Screenshots and source code is available at my website:
https://stormhub.org/simplehlr/
Best regards,
Peter Caprioli
