DTN IQFeed, DTN.IQ, DTN ProphetX Support Forums

Home

Recent Posts

Information on DTN's Industries:
DTN Oil & Gas | DTN Trading | DTN Agriculture | DTN Weather

DTN.IQ/IQFeed on Twitter
DTN News and Analysis on Twitter

About

Contact

Joined:	Jul 4, 2013 03:47 AM
Last Post:	Jan 29, 2014 09:02 AM
Last Visit:	Feb 26, 2015 09:21 AM
Website:
Location:
Occupation:
Interests:

Email:	sergiopeffe@gmail.com
AIM:
ICQ:
MSN IM:
Yahoo IM:

Post Statistics

mfgteam has contributed to 19 posts out of 21251 total posts (0.09%) in 4,093 days (0.00 posts per day).

20 Most recent posts:

IQFeed Developer Support » "strange" bd data Jan 29, 2014 09:02 AM (Total replies: 4)

thank you
regards

IQFeed Developer Support » "strange" bd data Jan 29, 2014 05:30 AM (Total replies: 4)

thank you!

IQFeed Developer Support » "strange" bd data Jan 29, 2014 12:16 AM (Total replies: 4)

Hi,

I am making this request, about 1 minute data of symbol BDH14

HIT,BDH14,60,20140128 162800,,,,,1,HIT$5
HIT$5,2014-01-28 16:31:00,0.6003,0.6003,0.6003,0.6003,692453,0,
HIT$5,!ENDMSG!,
HIT,BDH14,60,20140127 162800,,,,,1,HIT$5
HIT$5,2014-01-27 16:35:00,0.6403,0.6403,0.6403,0.6403,555182,0,
HIT$5,2014-01-28 02:02:00,142.46,142.43,142.43,142.45,2348,2348,
HIT$5,2014-01-28 02:03:00,142.49,142.45,142.46,142.48,3187,839,

I am receiving normal bars and then also strange bars with a very strange
price 0.6403...

Maybe it is normal, but I would like to know the meaning of this strange price with
a high volume.

Thanks,
mfg

IQFeed Developer Support » set protocol 5.1 Aug 21, 2013 08:53 AM (Total replies: 4)

sorry, my fault, I confused the HIT with the other message and the exception which I got mislead me.

I see now the other field. Thanks.

IQFeed Developer Support » set protocol 5.1 Aug 21, 2013 08:35 AM (Total replies: 4)

I have tested now. I receive a confirmation message about 5.1 and then, when I do the request this is the anwer

The exception is because I do not have the milliseconds in the date/time part.

I will investigate more about this, in the meantime I fall back to 5.0

Thanks

[882392] Sending request HIT,@ESU13,60,20130821 092800,,,,,1,HIT$1 to the socket
java.lang.IllegalArgumentException
[738281] The client has not been able to process HIT$1,2013-08-21 09:29:00,1647.00,1646.50,1646.75,1646.75,173884,922,0, I quit!
at com.mfg.dfs.iqfeed.IqFeedClient$HistorySocketListener._getUnparsedBarFromHixHidHitLine(IqFeedClient.java:734)
at com.mfg.dfs.iqfeed.IqFeedClient$HistorySocketListener.processLine(IqFeedClient.java:653)
at com.mfg.utils.socket.SimpleSocketTextClient.runMainLoop(SimpleSocketTextClient.java:191)
at com.mfg.utils.socket.SimpleSocketTextClient$DPThread.run(SimpleSocketTextClient.java:161)
at java.lang.Thread.run(Unknown Source)
[391933] The request is finished!

IQFeed Developer Support » set protocol 5.1 Aug 21, 2013 12:55 AM (Total replies: 4)

Hello,

I have updated to the new beta. If I set the protocol to 5.1 it seems that the HTT response does not have the millisecond information, like it was in 4.9.

Maybe it is an error in my part, but it seems strange, switching to the string "5.0" all goes well as before.

Regards

IQFeed Developer Support » repeatability of trade data history requests Jul 25, 2013 12:01 AM (Total replies: 7)

Hello,

I will follow your suggestion of using HTT instead of HTD, I will end up requesting less data.

Regarding the overlap I will try to be lenient, maybe it is some bug which I did not found yet.

Regards.

IQFeed Developer Support » repeatability of trade data history requests Jul 24, 2013 06:05 AM (Total replies: 7)

Hello,

yesterday there were no problems, also with the lenient flag turned off.

But now I have found the "same" strange thing, I receive one tick less.

This is my application log:


[738933] Catching up, I have 92 ticks saved to check
[882392] Sending request HTD,@ESU13,1,,,,1,HTD$2 to the socket
[393913] HISTORY: [1249] I am alive @ 24-07-13 07:44:18+0200 line: 1688.50,2,23735,1688.25,1688.50,4719587,C,43,01,
[381033] Overlap fail @ 15 for tick Tick [t Wed Jul 24 10:43:44 CEST 2013, tRAW 1374655424329 p 169225] it had to be Tick [t Wed Jul 24 10:43:32 CEST 2013, tRAW 1374655412514 p 169225]
java.lang.IllegalStateException
[738281] The client has not been able to process HTD$2,2013-07-24 04:43:50.022,1692.50,2,59750,1692.25,1692.50,4911504,C,43,01, I quit!
[418935] ----- ioexce java.net.SocketException: socket closed

Looking inside I see that I expect TWO ticks at the time 1374655412514 (java time)
which is 4.43.32.514 New York Time. But apparently you give me only one,
then the next tick is at 4.43.44 but I am still waiting the tick @ 4.43.32.514

It seems "strange" because the inconsistency is at the same time as yesterday,
more or less. So it seems strange that it is a bug on my side, because all yesterday
went fine (and I made a lot of tests)

In any case I can do a lenient comparison... just to let you know.

Thank you.

IQFeed Developer Support » repeatability of trade data history requests Jul 23, 2013 09:52 AM (Total replies: 7)

Hello,

I am doing the request as HTD, with a day of overlap, for example if the last
tick stored is yesterday, I will make a request of 2 days.

Then of course there will be trades which will be before the "glue" point, and
I simply wait for the sentinel tick which is the first which must match.

I have altered my software putting a "lenient" flag in which it accepts also a partial
match, I will put this flag to false and if the problem arises again I will post here
the data which my software thinks as incoherent.

Thank you

IQFeed Developer Support » repeatability of trade data history requests Jul 23, 2013 04:34 AM (Total replies: 7)

Sorry to write again, but I see now something strange.

The bug has been corrected and I am now testing.

I make some tick requests with some minutes distance.

This is the request

HTD,@ESU13,1,,,,1,HTD$3

I simply want to have one day of tick data from oldest to newest.

But I have seen something strange.

This is the part which is different

HTD$3,2013-07-23 04:30:57.146,1692.75,3,63549,1692.50,1692.75,2517378,C,43,01,
HTD$3,2013-07-23 04:31:27.661,1692.75,1,63550,1692.50,1692.75,2517482,C,43,01,
HTD$3,2013-07-23 04:31:27.661,1692.75,1,63551,1692.50,1692.75,2517483,C,43,01,
HTD$3,2013-07-23 04:31:27.661,1692.75,2,63553,1692.50,1692.75,2517484,C,43,01,
HTD$3,2013-07-23 04:31:27.661,1692.75,2,63555,1692.50,1692.75,2517485,C,43,01,
HTD$3,2013-07-23 04:31:27.661,1692.75,1,63556,1692.50,1692.75,2517486,C,43,01,
HTD$3,2013-07-23 04:31:27.661,1692.75,1,63557,1692.50,1692.75,2517487,C,43,01,
HTD$3,2013-07-23 04:31:27.661,1692.75,1,63558,1692.50,1692.75,2517488,C,43,01,
HTD$3,2013-07-23 04:31:27.661,1692.75,1,63559,1692.50,1692.75,2517489,C,43,01,
HTD$3,2013-07-23 04:31:27.661,1692.75,1,63560,1692.50,1692.75,2517490,C,43,01,
HTD$3,2013-07-23 04:31:27.661,1692.75,1,63561,1692.50,1692.75,2517491,C,43,01,
HTD$3,2013-07-23 04:31:27.661,1692.75,1,63562,1692.50,1692.75,2517492,C,43,01,
HTD$3,2013-07-23 04:31:27.661,1692.75,1,63563,1692.50,1692.75,2517493,C,43,01,
HTD$3,2013-07-23 04:31:27.661,1692.75,25,63588,1692.50,1692.75,2517494,C,43,01,
HTD$3,2013-07-23 04:31:27.661,1692.75,11,63599,1692.50,1692.75,2517495,C,43,01,
HTD$3,2013-07-23 04:31:27.662,1692.75,4,63603,1692.50,1692.75,2517516,C,43,01,
HTD$3,2013-07-23 04:31:27.662,1692.75,1,63604,1692.50,1692.75,2517517,C,43,01,
HTD$3,2013-07-23 04:31:53.076,1692.75,1,63605,1692.50,1692.75,2517758,C,43,01,

You can see that there are 14 trades with millisecond 661 and two trades with
millisecond 662

BUT, in a former run, I had 14 trades with millisecond 661 and THREE trades
(not 2) with millisecond 662.

The other data seem coherent. There is only this mismatch.

Is it a bug in my software or could it be that the stream of trades is not
100% reproducible?

Thank you

IQFeed Developer Support » repeatability of trade data history requests Jul 23, 2013 03:00 AM (Total replies: 7)

Never mind, I have found the bug, just an off by one. Unfortunately I am not able to delete my post...

IQFeed Developer Support » repeatability of trade data history requests Jul 23, 2013 02:44 AM (Total replies: 7)

Hello,

I am writing a software that tries to "glue" tick data for a particular symbol
each day at a certain hour.

I request a tick by tick data with some overlap with the old data which
I have already processed the day before and then, after the overlap has
finished, I start to record the ticks.

I use as a "glue" marker a certain number of trades.

The thing that I see is that from one day to the next there are some
very small differences in the number of trades, in the order of milliseconds,
or, different number of ticks.

Should I do a "lenient" match or this is a bug in my software because
the tick stream is fixed?

Thanks

IQFeed Developer Support » incoherence in high-low data (daily) Jul 16, 2013 09:14 AM (Total replies: 2)

thank you, I will update my parsing algorithm to handle this.

IQFeed Developer Support » incoherence in high-low data (daily) Jul 16, 2013 09:04 AM (Total replies: 2)

Hello,

sorry if I disturb you but I see this strange thing asking for daily bars

I make this request:

HDX,@ESU13,5000,1,HDX$1

5000 is just a big number, to say: "give me all that you have!".

HDX$1,2012-06-15,1312.00,1312.00,1312.00,1312.00,0,0,
HDX$1,2012-06-18,1315.25,1315.25,1315.25,1315.25,0,0,
HDX$1,2012-06-19,1325.00,1325.00,1325.00,1325.00,0,0,
HDX$1,2012-06-20,1325.00,1325.00,1325.00,1325.00,0,0,
HDX$1,2012-06-21,1292.50,1292.50,1292.50,1292.50,0,0,
HDX$1,2012-06-22,1300.75,1300.75,1300.75,1300.75,0,0,
HDX$1,2012-06-25,1305.00,1280.75,1305.00,1280.50,150,0,

The first bars have zero volume. And this is OK.

Then there is the first bar with volume != 0. But it has a low of 1280.75,
which is the second field, but a close of 1280.50

How is it possible that the low is greater than the close?

According to the API manual the fields are in this order: H, L, O, C...

what am I doing wrong? There are other examples of this.

Regards,
mfgteam.

IQFeed Developer Support » no time field Jul 16, 2013 07:18 AM (Total replies: 2)

sorry, it seems a protocol variant.

If I set the protocol to 5.0 I get only the date part.

If I do not set the protocol to 5.0 I get date and time.

So this seems that HDX has a protocol variance, but the document seems not telling it.

IQFeed Developer Support » no time field Jul 16, 2013 06:43 AM (Total replies: 2)

Hello, I do a simple daily request

HDX,@ESU13,5000,1,HDX9291
HDX9291,2012-06-15,1312.00,1312.00,1312.00,1312.00,0,0,
HDX9291,2012-06-18,1315.25,1315.25,1315.25,1315.25,0,0,
HDX9291,2012-06-19,1325.00,1325.00,1325.00,1325.00,0,0,
HDX9291,2012-06-20,1325.00,1325.00,1325.00,1325.00,0,0,
HDX9291,2012-06-21,1292.50,1292.50,1292.50,1292.50,0,0,

In the result I do not have the time information, but only the date.

This is OK, and it is not a surprise, but in the API document

http://www.iqfeed.net/dev/api/docs/HistoricalviaTCPIP.cfm

I see instead that the format is always with a time part

Example data: Request: HDX,MSFT,10<CR><LF>
2008-09-30 17:29:32,26.6911,25.5400,25.7700,26.6900,107076413,0,<CR><LF>
2008-09-29 17:29:32,27.6600,25.0089,26.9400,25.0100,134383096,0,<CR><LF>
2008-09-26 17:29:32,27.5600,26.1400,26.1700,27.4000,100744280,0,<CR><LF>

Am I missing something? (I have set the protocol to 5.0, but it seems that this
is not a protocol variant).

IQFeed Developer Support » Range bars? Jul 8, 2013 07:40 AM (Total replies: 2)

thank you very much.

it is not really a problem for us, but in this case I am sure about it.

IQFeed Developer Support » sequential or parallel history requests Jul 8, 2013 07:36 AM (Total replies: 1)

Hello,

I am doing some preliminary tests with the historical socket in iqFeed.

I have had the impression that iqConnect serializes the requests made through
the socket and I would like a confirmation about this.

I have made just to test two different historical requests one after another

_histSocket.writeLine("HTX,@ESU13,1000,1,T1,2");
_histSocket.writeLine("HTX,@ESZ13,1000,1,T2,2");

our aim is to collect historical data from different maturities to make
a trade strategy based on that.

I see that the 1000 data points come after one another, that is
first all the data points which starts with request T1 come and
then all the data points which starts with T2.

Can I assume that this is always the case? Would I never
have a mixture of lines from the socket, for example 3 lines
which starts with T1, then 2 lines that starts with T2, etc...?

Another question. If this is the case... from your point of you
is it the same if I made the two requests immediately or there
is nothing to gain (in speed) from making the first request,
collecting all data and then making the second request?

...

Another question, what if I opened two sockets to iqConnect
and made two parallel requests there? Would I gain something
in terms of speed?

Thanks

IQFeed Developer Support » Range bars? Jul 4, 2013 03:53 AM (Total replies: 2)

hello, sorry if this question is naive...

I am starting to study the API and I have a doubt regarding the "interval" query.

I would like to have "range bars", which are bars in which the difference between high
and low is constant.

I have tried to make this request:

HIX,@ESU13,0.25,10,1,TST,,t

my intention was to have bars with a 1 tick interval (0.25 in my case)
but I got this:

TST,2013-07-04 03:10:08,1613.50,1611.50,1612.00,1613.25,26203,2539,
TST,2013-07-04 03:17:35,1613.75,1612.25,1613.25,1612.25,28416,2213,
TST,2013-07-04 03:23:04,1613.75,1611.75,1612.25,1613.75,30861,2445,
TST,2013-07-04 03:28:31,1614.75,1613.25,1613.75,1614.50,34174,3313,
TST,2013-07-04 03:41:58,1615.00,1613.75,1614.50,1614.00,37325,3151,
TST,2013-07-04 03:54:28,1614.75,1613.75,1614.00,1614.00,39682,2357,
TST,2013-07-04 04:12:03,1614.50,1613.50,1614.00,1614.25,42289,2607,
TST,2013-07-04 04:31:04,1614.50,1612.75,1614.25,1613.50,45089,2800,
TST,2013-07-04 04:49:16,1614.25,1613.25,1613.50,1614.00,47958,2869,
TST,2013-07-04 04:51:09,1614.00,1613.75,1613.75,1613.75,48162,204,
TST,!ENDMSG!,

And clearly those bars have not a 0.25 tick interval fixed.

Sorry, I come from eSignal where I put "0.25R" as an interval and it worked.

Is there some corresponding string for a range bar or do I have to "build" them
from tick by tick data?

Thanks

Time: Mon September 16, 2024 4:36 AM

CFBB v1.2.0

7 ms.