mrf49xa component

For Flowcode users to discuss projects, flowcharts, and any other issues related to Flowcode 6.

Moderator: Benj

User avatar
mikn
Posts: 209
Joined: Mon Mar 03, 2014 10:11 pm
Has thanked: 54 times
Been thanked: 41 times
Contact:

mrf49xa component

Postby mikn » Fri Jan 23, 2015 1:57 am

Getting problems right from the beginning of new project. Assuming I will have more troubles with this component I create separate topic to collect everything about this mrf49xa.
Please can you give me more detailed documentation about functions you included in this component? Timeout definitions (in ms or us), valid ranges and values and so on. Some parameters cannot be understood correctly. :-\

Also I've got a trouble right from the start.
MRF Initialize gives me code 0 (error, according to the description) in Software mode with remapped pins.
But once I change to Channel1 all pins change to different that I have, and initialize result is 0xffff (not zero is ok?). How this can be if MOSI,MISO and SCK pins are wrong for me?
FC 6.1.3.2 (18.02.2016)

User avatar
mikn
Posts: 209
Joined: Mon Mar 03, 2014 10:11 pm
Has thanked: 54 times
Been thanked: 41 times
Contact:

Re: mrf49xa component

Postby mikn » Fri Jan 23, 2015 11:30 am

When changing from Software to Channel1 all pins remain the same. And I can't remap them
scremap.GIF
scremap.GIF (19.29 KiB) Viewed 11103 times

also when editing cal_spi component parameters in MRF component, it shows me completely different pins which I also can't remap.
scremap2.GIF
scremap2.GIF (28.93 KiB) Viewed 11103 times


any ideas?
FC 6.1.3.2 (18.02.2016)

User avatar
mikn
Posts: 209
Joined: Mon Mar 03, 2014 10:11 pm
Has thanked: 54 times
Been thanked: 41 times
Contact:

Re: mrf49xa component

Postby mikn » Sat Jan 24, 2015 8:58 pm

Ok, solved the problem with init. For some reason now it works. :-\

But got another problem with ReceiveByte macro. I set the timeout to 200ms however during receiving a byte (0xA8) from another device the receiver stucks for 4-5 seconds on this step and then return 255. Also receiving is 1 from 10 times (I press the button on sender and it transmits the byte). When the receive is ok, there are no such big delay.
What's the problem?

The project is attached.
Attachments
baza2.fcfx
(20.09 KiB) Downloaded 240 times
FC 6.1.3.2 (18.02.2016)

User avatar
mikn
Posts: 209
Joined: Mon Mar 03, 2014 10:11 pm
Has thanked: 54 times
Been thanked: 41 times
Contact:

Re: mrf49xa component

Postby mikn » Tue Jan 27, 2015 10:32 pm

How to use buffer in this component?
Is it FIFO or how to clear the incoming buffer? If FIFO then how to understand Index parameter in GetBufferData?
If not then how to clear the buffer after receiving a packet of 10 bytes, for example? Does it accumulate data until full or no? Please, give me more description on how to operate with MRF49XA buffer in FC.

Thank you.
FC 6.1.3.2 (18.02.2016)

User avatar
mikn
Posts: 209
Joined: Mon Mar 03, 2014 10:11 pm
Has thanked: 54 times
Been thanked: 41 times
Contact:

Re: mrf49xa component

Postby mikn » Wed Jan 28, 2015 10:54 pm

When using CheckBuffer what does Timeout property mean? Is it in ms? When I put 200, it returns 0xFF immediately, not waiting 200ms.
When I use Delay(100ms) in While loop between CheckBuffer requests I have lost packets. So should I check the buffer without delay? The more delay I set, the more packets are lost. How should I use CheckBuffer correctly? Give me example, please.
FC 6.1.3.2 (18.02.2016)

User avatar
Benj
Matrix Staff
Posts: 14676
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4660 times
Been thanked: 4286 times
Contact:

Re: mrf49xa component

Postby Benj » Thu Jan 29, 2015 11:11 am

Hello Mikn,

I believe the RF module itself is a FIFO but once you have read in the data then you overwrite any old data. I have had best results using this module with the circular buffer component as you can store the data into that until your ready to process or forward it on.

The CheckBuffer timeout is how many times to try and collect data from the module before giving up. Each attempt has 1us minimum and 100us if the module is not yet ready with data.

There is an example here. http://www.matrixtsl.com/wiki/index.php ... c3df2c0a22

I also made an RF / RS232 bridge in my spare time which worked very nicely after a lot of tweaking. I'll see if I can dig out the code for you.

User avatar
mikn
Posts: 209
Joined: Mon Mar 03, 2014 10:11 pm
Has thanked: 54 times
Been thanked: 41 times
Contact:

Re: mrf49xa component

Postby mikn » Thu Jan 29, 2015 1:16 pm

Thanks for examples, I will try them.

So by the logic if an application is doing some other code, the RF module must accumulate all packets and once I ask for CheckBuffer it must show me total bytes received (if 5 packets by 10 bytes transmitted then it must show 50 bytes, correct?).
Here is what I can't understand. I've got 2 devices laying 10cm from each other (so the signal is very good) and the more delay I have between Checkbuffer the more I have lost packets (checkbuffer still shows 255 after 2 seconds delay, however I have transmitted 5 packets). Once I remove delay at all and do

Code: Select all

while(1)
{
 b=checkbuffer(100)
}

(it's just an example)
it shows 50 packets. What may be the problem? For me it's like the Rf module does not receive anything until Checkbuffer macro is executed.
FC 6.1.3.2 (18.02.2016)

User avatar
mikn
Posts: 209
Joined: Mon Mar 03, 2014 10:11 pm
Has thanked: 54 times
Been thanked: 41 times
Contact:

Re: mrf49xa component

Postby mikn » Sat Jan 31, 2015 11:23 pm

I have reviewed the example. But still can't understand the thing - when does the FIFO buffer clear itself? During Checkbuffer or GetBuffetData?
When I receive 15 bytes, I can read them in buffer from [0] to [14]. But I can read them many times. So this means that the buffer does not flush at this moment.
When I send 3 times by 15 bytes and then use checkbuffer, it shows me only last 15 bytes in buffer. Does it mean, that I must constantly CheckBuffer and read data immediately to avoid missing next bytes? Buffer size in RF properties is set to 50 bytes.
Last edited by mikn on Tue Feb 03, 2015 12:17 pm, edited 1 time in total.
FC 6.1.3.2 (18.02.2016)

User avatar
mikn
Posts: 209
Joined: Mon Mar 03, 2014 10:11 pm
Has thanked: 54 times
Been thanked: 41 times
Contact:

Re: mrf49xa component

Postby mikn » Tue Feb 03, 2015 12:17 pm

When does the FIFO buffer clear itself?
FC 6.1.3.2 (18.02.2016)

User avatar
mikn
Posts: 209
Joined: Mon Mar 03, 2014 10:11 pm
Has thanked: 54 times
Been thanked: 41 times
Contact:

Re: mrf49xa component

Postby mikn » Wed Feb 04, 2015 4:26 am

One more problem.

Receiver has 50 bytes buffer, which checks with CheckBuffer(200) after button pressed.
Sender transmits 1 byte only once.
After 1 second I press button on Receiver.
The step CheckBuffer freezes for about 6 seconds instead of 200ms. then returns value 253 however there must be only 1 byte.
If I send 5-6 bytes, the value returned is 252.

What's the problem?

Receiver project included.
Also there's a problem with timing. When I set timeout to 100, it waits for 3 seconds.
Attachments
baza2pub.fcfx
(27.05 KiB) Downloaded 211 times
FC 6.1.3.2 (18.02.2016)

User avatar
mikn
Posts: 209
Joined: Mon Mar 03, 2014 10:11 pm
Has thanked: 54 times
Been thanked: 41 times
Contact:

Receiver buffer problem

Postby mikn » Thu Feb 05, 2015 1:11 am

Hi guys,

I continue my monologue even no one can answer to those questions which I ask. I hope that support will find some time to investigate my cases. :x
Here's one more problem I've met.

I have included two projects. "Client" sends two variants of packets (1 byte and 12 bytes, depends on the button pressed). "Baza" gets completely different data. I have included the photo of display.
Seems to be the big bug in the buffer. The project is simple and I don't know if the problem may come from other place than RF buffer.
baza1pub.fcfx
(13.36 KiB) Downloaded 233 times

client1pub.fcfx
(13.38 KiB) Downloaded 231 times

small193bytes.jpg
small193bytes.jpg (38.45 KiB) Viewed 11014 times

During the tests I've got some statistics on pressed buttons and received data:
1. sent 1 byte (pressed button 1) - got shit (as on photo).
2. sent 1 byte - got shit
3. sent 1 byte - got 1 byte
3. sent 12 bytes (button 2) - got 1 byte
4. sent 12 bytes - got 1 byte
.....
12.sent 12 bytes - got 12 bytes.
13. sent 1 byte - got 12 bytes.
...
also sometimes the data is mixed not in right order. Here's the log of values after pressing buttons 1 and 2 repeatedly:
55
55
55
1 12 1 2 3 4 5 6 7 8 9 10
1 12 1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8 9 10 11 12
1 2 3 4 5 6 7 8 9 10 11 12
1 2 3 4 5 6 7 8 9 10 11 12
FC 6.1.3.2 (18.02.2016)

hyperion007
Posts: 528
Joined: Sat Dec 01, 2012 1:23 pm
Location: Sweden
Has thanked: 49 times
Been thanked: 101 times
Contact:

Re: mrf49xa component

Postby hyperion007 » Thu Feb 05, 2015 6:54 pm

Hi Mikn,

I have very little experience from RF stuff and don't own any MRF49XA but I'll have a look at your attached programs and see if I can be of help. I will be back home in a couple of days hopefully (where I have my computer with FC on).
Feel free to remind me if you haven't heard anything from me by Tuesday next week.

//Daniel S
These users thanked the author hyperion007 for the post:
mikn (Thu Feb 05, 2015 7:20 pm)
Rating: 5%
 

hyperion007
Posts: 528
Joined: Sat Dec 01, 2012 1:23 pm
Location: Sweden
Has thanked: 49 times
Been thanked: 101 times
Contact:

Re: mrf49xa component

Postby hyperion007 » Sat Feb 07, 2015 4:02 pm

Ok, I've had a look but I don't know what is causing your problems.

First I would try to create an even simpler program than your client1pub and baza1pub.

I've made an attempt at a new client1pub and baza1pub that only uses two bytes in the buffer and the baza1pub should display one odd and one even number on the display, and it should count up to 255 where it will roll over to 0.
Display should look like this:

Receive
1, 2

Then:

Receive
3, 4

etc.

It's been a while since I used FC so I might have missed something.

Please let me/us know if/how it works.

baza1pub.fcfx
(11.94 KiB) Downloaded 216 times


client1pub.fcfx
(9.65 KiB) Downloaded 205 times
These users thanked the author hyperion007 for the post:
mikn (Sun Feb 08, 2015 7:11 pm)
Rating: 5%
 

User avatar
mikn
Posts: 209
Joined: Mon Mar 03, 2014 10:11 pm
Has thanked: 54 times
Been thanked: 41 times
Contact:

Re: mrf49xa component

Postby mikn » Sun Feb 08, 2015 7:13 pm

Thanks! Is it hardware result or emulation?
Will try the code soon
FC 6.1.3.2 (18.02.2016)

hyperion007
Posts: 528
Joined: Sat Dec 01, 2012 1:23 pm
Location: Sweden
Has thanked: 49 times
Been thanked: 101 times
Contact:

Re: mrf49xa component

Postby hyperion007 » Tue Feb 10, 2015 6:50 pm

Hi Mikn,

I haven't tried simulation nor on hardware.

User avatar
mikn
Posts: 209
Joined: Mon Mar 03, 2014 10:11 pm
Has thanked: 54 times
Been thanked: 41 times
Contact:

Re: mrf49xa component

Postby mikn » Wed Feb 11, 2015 4:19 pm

Here's the video file with result. https://www.sendspace.com/file/bw1da0

First data received was 1,2
Then it became 6,2
Then 12,2
Then 153,7
Then completely mixed and unknown.. :shock: :shock: :shock: :?
FC 6.1.3.2 (18.02.2016)

hyperion007
Posts: 528
Joined: Sat Dec 01, 2012 1:23 pm
Location: Sweden
Has thanked: 49 times
Been thanked: 101 times
Contact:

Re: mrf49xa component

Postby hyperion007 » Wed Feb 11, 2015 6:08 pm

Ok, try this baza1pub file.

I have changed the CheckBuffer from 10 to 100 and also changed the delay in the main loop from 1 second to 100ms.

baza1pub.fcfx
(11.95 KiB) Downloaded 201 times


It sounds like it starts out fine with "1, 2" but then something happens. Maybe the CheckBuffer time was too short and/or the delay was too long.

Have you tried the example application found in the help wiki for the RF-ISM component? Does that work?
These users thanked the author hyperion007 for the post:
mikn (Wed Feb 11, 2015 9:15 pm)
Rating: 5%
 

User avatar
mikn
Posts: 209
Joined: Mon Mar 03, 2014 10:11 pm
Has thanked: 54 times
Been thanked: 41 times
Contact:

Re: mrf49xa component

Postby mikn » Wed Feb 11, 2015 9:15 pm

This variant is better. First digit is ok, but second always 2. Here's the link to the video: http://www.fileshare.ro/e31312379
Please, note on video, that even you set up timeout for checkbuffer = 100 (ms), but actually it freezes for about 1 second (display is off while receiving the data).
Seems like there's a problem with time calculation in this macro.

Have you tried the example application found in the help wiki for the RF-ISM component? Does that work?

Didn't try because I'm not sure if this is a problem with receiving data or transmitting data. But I have built the same loops and whole program flow related to the example. As you see in my previous examples, it doesn't work correctly. I am disappointed. :-\
FC 6.1.3.2 (18.02.2016)

User avatar
mikn
Posts: 209
Joined: Mon Mar 03, 2014 10:11 pm
Has thanked: 54 times
Been thanked: 41 times
Contact:

Re: mrf49xa component

Postby mikn » Thu Feb 12, 2015 2:40 am

I give 100% that it's a bug with buffer.
I send 2 bytes, but wrote 44 in total buffer length to send to see what will happen (I expected my two bytes and 42 bytes of trash):
send-recv-codes.GIF
send-recv-codes.GIF (13.82 KiB) Viewed 10927 times

But I got 1 my byte, then length of the packet.
http://www.fileshare.ro/e31312972 - BR follow this at your own risk!!!!!
reuploaded - https://www.sendspace.com/file/q4xk55
Played with different values, same story.

I will be kindly await for Matrix staff comment on this as they shamelessly ignore this thread and my requests via their website to help me to resolve the issue.
Last edited by mikn on Thu Feb 12, 2015 2:55 pm, edited 1 time in total.
FC 6.1.3.2 (18.02.2016)

User avatar
Benj
Matrix Staff
Posts: 14676
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4660 times
Been thanked: 4286 times
Contact:

Re: mrf49xa component

Postby Benj » Thu Feb 12, 2015 11:07 am

Hello Mikn,

I will see if I can get some time today to try and help with this. These modules have always been a bit troublesome. I find that once they work they work very well but getting them to work reliably can be tricky. A lot of the problems can be down to the RX and TX settings. If you are sending data constantly then the receiver locks on and starts to reliably receive. However if you are transmitting in short bursts then the receiver has a very hard time.

As I say I have created an RS232 bridge with these modules which works very well but I remember getting it stable was troublesome to say the least. What are you using in the way of antennas?

Also the link you posted is trying to give my computer a virus, not cool!

virus.jpg
virus.jpg (19.9 KiB) Viewed 10920 times
These users thanked the author Benj for the post:
mikn (Fri Feb 13, 2015 4:07 am)
Rating: 5%
 

User avatar
mikn
Posts: 209
Joined: Mon Mar 03, 2014 10:11 pm
Has thanked: 54 times
Been thanked: 41 times
Contact:

Re: mrf49xa component

Postby mikn » Thu Feb 12, 2015 2:53 pm

I have reuploaded to another server: https://www.sendspace.com/file/q4xk55
I am on linux and don't get any virus messages.

What are you using in the way of antennas?

Cut of wire 173mm length.

However if you are transmitting in short bursts then the receiver has a very hard time.

Yes, this is what I need - Sender transmits a packet once the button is pressed. Receiver gets it and show on display. Once a minute, around that.

The problem is that you know what code is inside your macros (Checkbuffer, Sendbyte, Receivebyte,etc..) and I don't. I rely on the description, but I get completely different things. So the more information you can provide me with all those troubles you had in the past, the less questions I will ask.
I see that I attack the forum with messages like AK-47 and bore you with questions, but I do the work and do some projects. And they are time dependant. The most part of the project works perfect, but there are some parts (like this RF) where I stuck in and need your assistance as a creator of FC.

By the way, can I use CAL_SPI to have direct access to RF while I already initialized the RF module with standart component? Do I need to initialize CAL_SPI too or just start sending bytes to RF?
Could you show me in PM the code of your bridge project, those parts with settings of RF module and parts where you send/receive bytes, please?
FC 6.1.3.2 (18.02.2016)

User avatar
mikn
Posts: 209
Joined: Mon Mar 03, 2014 10:11 pm
Has thanked: 54 times
Been thanked: 41 times
Contact:

Re: mrf49xa component

Postby mikn » Fri Feb 13, 2015 4:05 am

While you were sweetly sleeping and dreaming about Flowcode great future I made several new tests.
Now sender transmit 3 bytes every 1 second, receiver prints them upon receive.
Video: https://www.sendspace.com/file/5opkyg

Look on 0:0:15, the length of the received buffer (3) is put to byte 2 for some reason. And this problem repeats after several times.
Also, this byte is inserted into the buffer raw, not replaced some byte. I made next test with transmitting b, b+1, b+3 and it showed me b,PacketLength,b+1

I believe there's a major bug in CheckBuffer. Benj, look into this macro please as soon as you'll have time. My project is stuck. The world is crashing.
FC 6.1.3.2 (18.02.2016)

User avatar
mikn
Posts: 209
Joined: Mon Mar 03, 2014 10:11 pm
Has thanked: 54 times
Been thanked: 41 times
Contact:

Re: mrf49xa component

Postby mikn » Wed Feb 18, 2015 12:29 pm

Gimme examples of the code from your project, Benj. Please.
FC 6.1.3.2 (18.02.2016)

User avatar
Benj
Matrix Staff
Posts: 14676
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4660 times
Been thanked: 4286 times
Contact:

Re: mrf49xa component

Postby Benj » Wed Feb 18, 2015 1:09 pm

Hello Mikn,

Right sorry about leaving you for so long, here is the current source for the component so you can investigate this and make any changes if needed.

RF-ISM.fcfx
(93.66 KiB) Downloaded 227 times


I'm going home for lunch shortly so I will dig out and post the example code for you, the only downside is I think it was written using Flowcode v5 however hopefully you will be able to replicate my TX/RX settings.

I've also got some boards setup here so I'll do some testing and see if I can find a way to make things better.
These users thanked the author Benj for the post:
mikn (Wed Feb 18, 2015 3:07 pm)
Rating: 5%
 

User avatar
mikn
Posts: 209
Joined: Mon Mar 03, 2014 10:11 pm
Has thanked: 54 times
Been thanked: 41 times
Contact:

Re: mrf49xa component

Postby mikn » Wed Feb 18, 2015 4:11 pm

Thanks.
Here's the first issue I think I have found.
During Checkbuffer(XXms) I have much bigger delay than XXms value due to a possibly invalid calculation of us/ms.
Here's what my compiler says:

Code: Select all

Caution: argument of 'delay_us' calls must have a value of 1 or more
Caution: Delay inaccurrate: 'delay_us', Delay overhead:0.0045ms, Unit delay:0.001ms, Delay resolution:2 units

I see you're using microsecond delays to calculate timeout. Aren't they become invalid or converted to ms if I use 8mhz chip speed (I see, you use 49mhz)?
FC 6.1.3.2 (18.02.2016)