I seem to be having a strange issue. Using Sim808 modem, I am periodically sending SMS out.
With my AT+CMGS command, I get an OK and that the SMS was sent to the operator, but it never reaches the destination. Using the same SIM card in a phone, I am able to send SMS just fine.
This is my sms command response
>AT+CMGS="+919577634145",145
> Keedaaaa
0
0
(16/1/18 10:27:2)
60% 3884mv
4184
24.31C
(16/1/18 10:25:20)
64% 3917mv
4189
24.48C
+CMGS: 186
OK
And these are my modem initialization steps
[0:1:19] External_sim808 - Connecting to network...
RDY
+CFUN: 1
+CPIN: READY
*PSUTTZ: 2018,1,16,4,54,49,"+22",0
DST: 0
+CIEV: 10,"40445","airtel","AIRTEL", 0, 0
>AT+IPR=9600
OK
uart flag = 0x1
>ATE0
OK
uart flag = 0x1
>AT
OK
uart flag = 0x1
>AT+CLTS?
+CLTS: 1
OK
uart flag = 0x1
>AT+CMEE=1
OK
uart flag = 0x1
>AT+CMGF=1
OK
uart flag = 0x1
Call Ready
SMS Ready
>AT+CPMS="ME","ME","ME"
+CPMS: 0,50,0,50,0,50
OK
uart flag = 0x1
>AT+CMGDA="DEL ALL"
OK
uart flag = 0x1
>AT+CSQ
+CSQ: 28,0
OK
uart flag = 0x1
>AT+COPS=0
OK
uart flag = 0x1
>AT+CREG?
+CREG: 0,5
OK
uart flag = 0x1
[0:1:58] External_sim808 - network registration ok
Weird thing is, this only seem to happen on some service provider networks. On some others, the SMS go out just fine.
I have checked and ensured that the module has the right SMSC number.
Is there any other setting that I need to do? Or execute any other command to atleast help me in figuring out what could be happening here?
Related
I have created raw socket as below
rawSockfd = socket(AF_INET,SOCK_RAW,IPPROTO_IP)
Added flag 5 sec SO_RCVTIMEO, IP_HDRINCL to 1 via setsockopt.
Sending IP Packet as below:
struct sockaddr_in connection = getSockAddr(dstIPAddress);
long bytes = sendto(rawSockfd, (uint8_t *)packet, size, 0, (struct sockaddr *)&connection, sizeof(struct sockaddr));
I am trying to receive as below:
long rsize = recvfrom(rawSock, buffer, size, 0, (struct sockaddr *)&connection, (socklen_t *)&addrlen);
This works fine for ICMP, UDP. recvfrom able to read packet back.
We are facing issue during TCP. recvfrom returns error: Resource temporarily unavailable after 5 sec timeout. If we remove timeout flag SO_RCVTIMEO then it gets stuck forever.
TCPdump shows following logs on destination. Instead of SYN ACK it's getting Reset:
09:21:03.972632 IP 10.215.179.1.54745 > 10.207.134.154.8181: Flags [SEW], seq 358899317, win 65535, options [mss 1380,nop,wscale 6,nop,nop,TS val 426499980 ecr 0,sackOK,eol], length 0
09:21:03.972755 IP 10.207.134.154.8181 > 10.215.179.1.54745: Flags [R.], seq 0, ack 358899318, win 0, length 0
is this something macOS not sending TCP response back to rawsocket or something is wrong in my code? On linux, it is working fine.
I'm trying to emulate data from the 10-bit AEAT-6010 rotary encoder and send it out on the MISO pin of the SPI protocol on the ATtiny3217. The ATtiny act as a slave and receive a CLK and SS signal as input to respond to by outputting the data(encoder value). The encoder follows the SSI protocol to send data as shown below:
The problem arrises when trying to send 10 bits voer the 8 bit SPI protocol on the ATtiny. The master of the SPI protocol is the TMS320F2808 chip and from it I receive 11 clock pulses and the SS signal. The measured signals and data is shown below:
Here the data I try to send is 0b10 just for testing. I can see the correct data on the MISO line, but there is three 1's extra in the middle of the signal. This is with BUFEN=1 and BUFWR=1 in the SPI settings of the ATtiny as can be seen in the configuration below(without buffer mode the three 1's comes on the last 3 bits, and aslo the first bit(MSB) is read as a 1):
int8_t SPI_0_init()
{
SPI0.CTRLA = 0 << SPI_CLK2X_bp /* Enable Double Speed: disabled */
| 0 << SPI_DORD_bp /* Data Order Setting: enabled */
| 1 << SPI_ENABLE_bp /* Enable Module: enabled */
| 0 << SPI_MASTER_bp /* SPI module in slave mode */
| SPI_PRESC_DIV4_gc; /* System Clock / 4 */
SPI0.CTRLB = 1 << SPI_BUFEN_bp /* Buffer Mode Enable: enabled */
| 1 << SPI_BUFWR_bp /* Buffer Write Mode: enabled */
| SPI_MODE_0_gc /* SPI Mode 1 */
| 0 << SPI_SSD_bp; /* Slave Select Disable: disabled */
SPI0.INTCTRL = 0 << SPI_DREIE_bp /* Data Register Empty Interrupt Enable: enabled */
| 1 << SPI_IE_bp /* Interrupt Enable: enabled */
| 0 << SPI_RXCIE_bp /* Receive Complete Interrupt Enable: disabled */
| 0 << SPI_SSIE_bp /* Slave Select Trigger Interrupt Enable: disabled */
| 0 << SPI_TXCIE_bp; /* Transfer Complete Interrupt Enable: disabled */
return 0;
}
I have confirmed that the data fromat of the SPI module of the TMS320F2808 and the ATtiny is the same(read on falling clock edge). Is there something I am missing about how the buffers of the SPI work or the interrupts of the SPI? I'm not sure what to to in the ISR when enabling different interrupts(oher than clearing the flags). This is my main function(The ISR is empty for now):
int main(void)
{
/* Initializes MCU, drivers and middleware */
atmel_start_init();
sei(); // Enable global interrupts
/* Replace with your application code */
while (1) {
SPI_transmit(enc_data_L);
}
Where the SPI_transmit() is as follows:
void SPI_transmit(uint16_t enc_data)
{
// Then start the transmission by assigning the data to the SPI data register
SPI0.DATA = enc_data;
//SPI0.DATA = enc_data_H;
// Now wait for the data transmission to complete by periodically checking the SPI status register
//the SPI_IF is the only interrupt flag with a function in non-buffered mode.
while(!(SPI0.INTFLAGS & (SPI_RXCIF_bm)));
SPI0.DATA; //Dummy read to clear flag
}
I have also tried splitting the 16 bit data, as suggested here, but the problem remains also for 8-bit data. Hope this is enough background info. I'm thankful for any ideas!
in SPI_transmit after writing to the buffer you're waiting until transmission is completed. After that the input buffer is being fully transmitted and now is empty.
while(!(SPI0.INTFLAGS & (SPI_RXCIF_bm))); // waits until data is transmitted
RXCIF is set when there is a data in the receive buffer, i.e. the transmission of the output buffer was also completed.
Therefore, when next byte is being transmitted by the master, there is no new data yet in the output buffer to transmit. Probably the SPI module just repeats transmission of the previous byte.
So, instead of waiting for RXCIF flag, wait for DREIF flag, which will be set, when the transmission buffer is empty and ready for the next byte.
You can just ignore the incoming data, since you're not use it anyhow
void SPI_transmit(uint16_t enc_data)
{
// Wait until buffer is ready to get the next data byte
while(!(SPI0.INTFLAGS & (SPI_DREIF_bm)));
// Then start the transmission by assigning the data to the SPI data register
SPI0.DATA = enc_data;
// Don't care about read buffer
}
I get some stupid error's if I want to try initialise the connection from the TWI master to the bus. The start condition will be send but the processor waits in the infinity loop bevor starting to send the slave address to the bus.
I also have analysed the signals on the bus and one result is that the clock is running but there will be no data send on the bus.
The processor wait's in the line with the marked arrow.
We use the following code to start the and initialise the bus ...
void i2c_master_init() {
TWBR = (uint8_t)TWBR_val;
}
void i2c_master_stop() {
TWCR = (1<<TWINT) | (1<<TWEN) | (1<<TWSTO);
}
uint8_t i2c_master_start(uint8_t address) {
TWCR = 0;
TWCR |= (1<<TWSTA);
TWCR |= (1<<TWEN);
TWCR |= (1<<TWINT);
while( !(TWCR & (1<<TWINT)) ); <--
[...]
}
Currently I don't know, what's going wrong with the code. Or am I doing something else wrong. Can anyone help me?
Thank you in anticipation.
My best guess without hardware on my bench is that you should set all flags to TWI control registry at once by TWCR = (1<<TWINT)|(1<<TWSTA)|(1<<TWEN). Meanwhile you set them one by one in 3 separate operations (multiple clock cycles), while datasheet implicitly says flags must be set together, see also datasheet examples.
I have Raspberry PI 3 connected via SPI to AVR Attiny26, which in turn has a LCD connected to it. I am trying to get the SPI running,
Now, the issue is that when I set up the AVR for two wire mode and don't configure pull-up on PB1 (MISO commented out):
USICR = (1<<USIOIE)|(1<<USIWM1)|(1<<USICS1); // Enable USI interrupt - USIOIE=1
// Three wire mode USIWM1=0, USIWM0=1
// Two wire mode USIWM1=1, USIWM0=0
// External clock USICS1=1
//PORTB |= (1<<SPI_MISO); // Enable pull-ups on SPI port
DDRB = 0b01001010; /* Set PORTB bits: 7-4 as input
-- PB7 - Pushbutton (KEY1)/RESET
-- PB6 - Pushbutton (KEY2)/INT0
-- PB5 - ADC8 (T2)
-- PB4 - ADC7 (T1)
-- PB3 - PUMP
-- PB2 - SCK - 0 = external clock (input)
-- PB1 - MISO (output)
-- PB0 - MOSI (input) - */
ISR(USI_OVF_vect) {
disp[counter++] = USIDR;
if(counter==16)
counter = 0;
USISR |= (1<<USIOIF);
}
I get the string transfered and printed on the LCD.
However, when I change the AVR to work in three wire mode and/or enable PB1 pull-up, all I get is garbage. Neither the received characters match the ones sent, nor does their count.
Raspberry is the master here, providing all the clocking, the setup there is always the same (default, three wire mode) and the clock is reasonably slow.
int main(int argc, char **argv) {
int res = bcm2835_init();
printf("BCM2835 Init() = %d\n", res);
res = bcm2835_spi_begin();
printf("BCM2835 Begin() = %d\n", res);
bcm2835_spi_setClockDivider(BCM2835_SPI_CLOCK_DIVIDER_65536);
char data[16];
sprintf(data,"%s","<--Some data-->");
int len = strlen(data);
printf("Sent: %s\n", data);
bcm2835_spi_writenb(data, len);
exit(0);
}
Same results with spidev_test program using ioctl, so does not seem related to the library/Pi's program.
On top, what is puzzling me is that when I disconnect the wire from PB1 (MISO), I immediately start receiving garbage from Pi. As if Pi's SPI immediately starts clocking when PB1/MISO goes afloat.
What am I missing here?
Regretfully, I have to say that this one goes into the RTFM category.
After some reserch I found that Pi GPIO works with +3.3V. The Attiny was set to use+ 5V. After rewiring the AVR to work with 3.3V as well, everything seems to be working.
The reason why it worked in two wire mode is the absence of AVR's pull-up resistors (external required), which allowed Pi to use its own and drive the AVR pins in the range acceptable to both Pi and AVR. Enabling pull-ups on AVR would drive Pi's GPIO over the limit. Apparently no damage done, only unpredictable and hard to explain behavior.
I'm using pimd in my project. https://github.com/troglobit/pimd.
PIM daemon creates a 'pimreg' virtual interface.
Multicast routing works perfectly. but I'm curious why do we need 'pimreg' interface at all.
The code which handles virtual interface creation in kernel is:
static struct net_device *ipmr_reg_vif(struct net *net, struct mr_table *mrt)
{
struct net_device *dev;
struct in_device *in_dev;
char name[IFNAMSIZ];
if (mrt->id == RT_TABLE_DEFAULT)
sprintf(name, "pimreg");
else
sprintf(name, "pimreg%u", mrt->id);
dev = alloc_netdev(0, name, reg_vif_setup);
if (dev == NULL)
return NULL;
dev_net_set(dev, net);
if (register_netdevice(dev)) {
free_netdev(dev);
return NULL;
}
dev->iflink = 0;
rcu_read_lock();
in_dev = __in_dev_get_rcu(dev);
if (!in_dev) {
rcu_read_unlock();
goto failure;
}
ipv4_devconf_setall(in_dev);
IPV4_DEVCONF(in_dev->cnf, RP_FILTER) = 0;
rcu_read_unlock();
if (dev_open(dev))
goto failure;
dev_hold(dev);
return dev;
failure:
/* allow the register to be completed before unregistering. */
rtnl_unlock();
rtnl_lock();
unregister_netdevice(dev);
return NULL;
}
and I see most of the time tx and rx packets are 0.
ifconfig pimreg
pimreg: flags=193<UP,RUNNING,NOARP> mtu 1472
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 0 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
On further debugging I found all PIM packets are lifted from kernel to userspace through pim_socket.
So why do we need pimreg virtual interface on first place?
What is the linux kernel pimd design objective for this.
The pimreg interface is created by the kernel when pimd opens
the multicast routing socket and performs its ioctl magic.
The interface is used for register tunnels, i.e. when tunneling
multicast stream(s) from the rendez-vous point (RP) to the designated
router (DR).
More information about this is available in RFC4601.