All diagnostic tests can be controlled by three CU services – test start, test report and test stop.
These services are activated by commands
sto(p), which are present in the submenu of each test. The
remaining menu items serve for editing of test parameters.
Anytime a test is successfully started, it has been started with
parameters sent from
Setr.exe together with the start
command. Consequently, the only way how to change a parameter of a running
test is to stop it, set the parameter and start the test again.
This enables complex testing of a path in the MORSE network.
From MORSE main menu type i t t Enter
Statistic (t)est:RX/TX (N):1 (d):690F8606h s(o)urce:- d(a)ta:abcdefg random data (l)ength:0byte (r)epeat period:1000ms + (j)itter:200ms Qualit(y) time constant:10s RSS (m)easure:ON sec(u)rity:OFF (g)o on:OFF (s)tart r(e)port sto(p) >>
— mode of test
Mode selection influences the rest of the menu, as items not relevant to the selected mode are not available for editing.
— The number of the node where the test will run. The node is from the CU where the test start service is activated. Simultaneously, the node selected is the originating node of the tested path.
— Address of Node, which is at the opposite end of the path to be tested.
— Only for RX mode. Address of the counterpart node (which has to be in the TX mode) transmitting test packets.
— Arbitrary data, which are then added to every test packet, can be set here.
type a Enter
Data: /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /A /B /C /D /E /F ASCII: 61 62 63 64 65 66 67 abcdefg Data: (a) ASCII (h)ex (r)andom (c)lear (S)um (q)uit >>
— random data will be added to every test packet (a new set of random data for every packet)
— period of test packet transmitting
— a random part is added to every period
— time constant used in calculations of immediate path quality (the packets coming in last 10 second are counted with bigger emphasis)
— RSS and DQ value is added to the test packet on every RF link on the path
— test packets are sent in non-secured mode (no ACK and no retransmissions on RF links)
— starts the test
— gets report from the running test
— gets report and stops the running test
type s Enter
Test on Node 1 is running
Type p Enter
STest report STOP!!! RX_TX source 690F8100 dest 690F8606 Node 1 security OFF current sec: 44318 test sec: 35204 packets send: 35135 received: 34906 bytes per packet: 112 period: 1002.0 ms PINGS TX: 35135 RX: 34906 Lost: 229 min: 174 max: 320 aver: 201 qual: 235 ms 160: 16726 192: 16913 224: 286 256: 981 Path DQ RSS HOM Path DQ RSS HOM (690F8100-690F0300) 29.3 62.6 0.9 (690F0300-690F8606) 26.9 95.2 0.7 (690F8606-690F0300) 28.4 92.1 0.9 (690F0300-690F8100) 29.9 65.3 0.8 PER: 1:153.4 BER: 7.3e-06 breaks count: (length: count) 1: 221 2: 4 8: 1 longest breaks: (units: sec) 8: 20131 2: 2735 2: 19115 2: 34065 2: 35062 1: 400 1: 487 1: 526 1: 750 1: 1197 1: 1400 1: 1407 >>
— test mode
— originating Node address
— destination Node address
— number of the originating Node within the source CU
— security setting (see above)
— time in seconds after the last cold start of source CU
— duration of the test
— number of packets transmitted
— number of packets received
— the average length of received packet
— the average period
— part of the test report dealing with response time statistic
— number of transmitted packets
— number of received packets
— number of lost packets
— the shortest response time
— the longest response time
— the average response time
— path quality is a number calculated from response times,
using a special algorithm with parameter
— there were 16726 pings between 160 and 192 ms etc. – this shows the distribution of response times
— RF link (from – to)
— Data Quality – average
— Received Signal Strength – average
— RSS homogenity value (calculated in a similar way to standard deviation)
— Packet Error Ratio (the probability that a packet is lost or corrupted)
— Bit Error Ratio (the probability that any received bit differs from that originally transmitted, the value is calculated from PER)
Next list displays the distribution of break lengths, where a break is understood to be a succession of lost packets; consequently break length is the length of the break measured in packets (the number of successive lost packets).
— one packet was lost 221×
— two successive packets were lost 4×
— from 8 to 11 successive packets were lost 1×,
— time in seconds (from the last cold start) of individual breaks, listed according to the size of the break. The 12 longest are entered
— all packets with break longer than 32768, i.e. very substantive drop-out
The BER test is a special test for evaluating the bit error rate. For the most part, it is used for laboratory measurement of the modem on a given fixed link where it is not necessary to reveal as much data in the report as in the Statistic test. When measuring the radio link, it is best to use the Statistic test.
On one side of the link, the BER Test must be set for transmission
(t)est TX; the other side (the side to be evaluated) must
be set for receiving
(t)est RX. The setting for other
parameters is contained in the section Statistic test.
The Ber test runs a one way Statistic test (one side TX, the other RX). Only the report is arranged to display only the bit error rate. The Ber is calculated from lost packets and their length.
From MORSE main menu type i t b Enter.
Ber (t)est:TX (N):1 (d):690F8100h s(o)urce:- d(a)ta: random data (l)ength:10byte (r)epeat period:1000ms + (j)itter:0ms (s)tart r(e)port sto(p) (q)uit >>
— determination of TX Node
— address of RX Node
— and other items – see Section 21.1, “STATISTIC TEST”
Ber (t)est:RX (N):1 (d):690F8100h s(o)urce:8606h d(a)ta:- random data (l)ength:- (r)epeat period:- + (j)itter:- (s)tart r(e)port sto(p) (q)uit >>
— determination of RX node
— not used
— the lower word of TX node address (the upper word has to be equal to that of the RX node address)
Ber report only RX source 00008606 dest 690F8100 packets received: 403 bytes per packet: 14 PER: 1:101.8 BER: 8.7e-05 >>
— probability of packet lost
— probability of bit lost (counted from packet size)
This test is used to transmit a precisely defined packet. With this service, it is possible to send a packet of any type and data structure to the MORSE network.
MORSE main menu type i t s Enter
Send packet: (N):1 (d):690F0300h (t)ype:0009h s(o)urce:690F8100h d(a)ta:abcd random data (l)ength:0byte (r)epeat period:1000ms + (j)itter:0ms (s)tart r(e)port sto(p) (q)uit >>
determination of the originating node
— destination address
— type of packet
— source address (can be different from the originating node
The other parameters follow the statistic test submenu. There is
one speciality about the Send packet test – when the
period is set to zero, the test starts by
command, sends just one packet according to parameters and immediately
stops itself (a one “shot” operation). In this case, a service report
limited to “O.K.” comes as a response to the
Normally, for periodical transmission, a response to the
r(e)port command looks like this:
SPack report source 690F8100 dest 300 Node 1 repeat period 1000 ms data size 4 bytes >>
The Ping test is a Statistic test but with the report arranged so
that a table with the response-times is displayed. If the
(m)easure is ON, the RSS/DQ table of RF links is also
From MORSE main menu type I t p Enter
Ping: (N):1 (d):69601000h sec(u)rity:OFF (g)o on:OFF RSS (m)easure:ON (r)epeat period:1000ms + (j)itter:0ms random data (l)ength:0byte Qualit(Y):OFF Qualit(y) time constant:10s d(a)ta: (s)tart r(e)port sto(p) (q)uit >>
For the meaning of remaining items see Section 21.1, “STATISTIC TEST”
Ping report Node 1 source 690F8100 dest 69601000 security OFF PINGS TX: 115 RX: 114 Lost: 1 min: 462 max: 1051 aver: 559 qual: 552 ms 448: 22 512: 86 640: 1 896: 4 1024: 1 Path DQ RSS HOM Path DQ RSS HOM (690F8100-690F0300) 29.2 64.9 0.8 (690F0300-69501500) 30.4 70.1 0.3 (69501000-69601000) 29.9 99.0 0.0 (69601000-69501000) 28.8 96.4 0.9 (69501500-690F0300) 22.8 70.4 0.8 (690F0300-690F8100) 29.4 66.9 0.6 >>
For the meaning of remaining items see statistical test report
The Round test simulates a polling-type user application i.e. calling to more CU from one centre, each of them separately. The test sends echo packets to selected group of destination Nodes. The lost packet probability and the average response time information are then available for every destination tested. This test is mostly used for network acceptance tests or as a network traffic generator, while the more detailed diagnostic information can be obtained from statistic logs from all participating CUs.
From MORSE main menu type i t r Enter
Round test: (N):1 (d) d(a)ta: random data (l)ength:0byte (r)epeat period:1000ms + (j)itter:0ms sec(u)rity:OFF (g)o on:OFF (s)tart r(e)port sto(p) (q)uit >>
— determining the originating Node
— list of destinations
type d Enter
Rtest editor (c)lear e(x)ample ( 1)e 0300 ( 2)e 0400 ( 3)e 8606 (q)uit >>
Only the lower word of the destination address can be configured in the editor, the upper word always equals the upper word of the originating Node address.
The editor line starts with one of the following letters:
— and other items – see the Section 21.1, “STATISTIC TEST”.
RTest report source 690F8100 total TX 205 Node 1 security OFF [dest - TX/PER/ping] 300h - 69/1:69.0/96 400h - 68/1:+INF/230 8606h - 68/1:1.0/-NAN >>
— address of the originating Node
— the total number of packets transmitted
— number of the originating Node
— test packets are transmitted as unsecured
In the example shown there was one lost packet to destination
690F0400 was OK and
690F8606 was switched off.
The memload test is used for loading one of the SW modules (MORSE
A, B, E, W) from the source CU to the destination one. Loading of a new
firmware module into an CU is a complex process and should be reserved
for trained personnel only. Attempts to remotely load SW modules made by
an unqualified person can have disastrous consequences for the network.
The following paragraphs deal only with the respective
Setr.exe menu and do not completely describe the
software loading process! For more information, please contact RACOM
technical support engineers (see www.racom.eu).
From MORSE main menu type i t l Enter
Memload: (N):1 (d):690F8100h (E)xternal flash:OFF ma(x) sectors:1 (m)odule:A User module: fi(r)st:00300000 (l)ast:0037FF80 (s)tart r(e)port sto(p) go MORSE (A)/(W) (i)nit (f)ire (k)ill (c)ontinue go MORSE (B) (q)uit >>
There are three different types of items in the memload menu:
Memload parameters, which have to be set before the test is initiated by the
sto(p)commands with standard behaviour
Memload commands, which can only be applied to a running test. These commands are used to proceed from one state to another during the loading process.
— source Node in the CU
— destination Node (in the CU where the selected SW module will be be loaded to)
— when this switch is ON, the selected software module is loaded into the external flash, which has to be connected to the main processor bus (used in production only)
— max. number of memory sectors per packet (for the purpose of memload, the memory sector size is set to 128 bytes, regardless of the actual flash sector size)
— choose the SW module to be loaded, see submenu
— arbitrarily selected interval from the CU memory
— start address of the memory interval
— end address
— starts MORSE A (W) in the destination CU
— activates the connection between the Node, where the
memload test runs, and the destination node. It is necessary to
— starts the loading
— forces interruption of the loading
— continues the loading process
— by starting MORSE B this command performs a cold start of the destination CU
The memload report provides complete information about the current status of the loading process:
This is Memload v1.03 response max. MF sectors per packet :4 loading module: MORSE A target : 690F5513h status :ready Check result: none begin : 374000h end : 37D800h current: 374000h talking to MORSE E timeout 12000 Time elapsed: 0msec Transfer rate: nankbps
— the number of 128 byte sectors currently transferred in a packet
— the software module being loaded
— the destination node address
— the status of the loading process (error states are displayed here)
— the start address of the memory part being loaded
— the end address
– the start address of the currently transferred sector
— indication of the SW module running in the destination CU (this information can be invalid while in an error state)
— current value of the timeout
stop– when the report was performed before initialisation of the memload channel
memfill error No– an error state (followed by the error number)
data continuity error– a mismatch in addresses of sectors transmitted and acknowledged has been detected
waiting for memfill response– normal state during loading
all sectors are O.K.– loading successfully completed
automated– automatic memload runs
ready– memload is prepared to start the loading process
1MF_CODE_ERROR – safeguard code error detected by the destination CU
2MF_RANGE_ERROR – attempt to enter an incorrect flash range
3MF_BOUNDARY_ERROR – attempt to enter an incorrect boundary sector
4MF_SIZE_ERROR – data delivered have a different size than the one stated in the header
Most error states can be resolved by the sequence of
(c)ontinue memload commands.